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1. Beschreibung: 

1.1 AufgabensteOung und Stand der Technik: 

5 AHein in Deutschland fehlen auf dem Gebiet der Software-Entwicklung z.Z. 80.000 Mitarbeiter 
und die Entwicklungs-Aufgaben warden immer komplexer. 

Bislang werden Programme nach gegebener Aufgabenstellung von Software-Entwicklern konzi- 
piert und programmiert. 

Zur Erleichterung der Programmierung gibt es bislang "Wizards", die mittels Dialog-Fenstern 
10 nach interaktiver Eingabe von Daten des Benutzers grundlegende Teile des Source-Codes nach 
fest vorgegebenen Schemata erstellen. 

Ferner werden auch firmenspezifische Skripte geschrieben, die mittels Auslesen von Oaten aus 
ASCII-Files einfache stetig wiederkehrende Teile von Sourcecodes generieren. 
In jedem Fall muS der Benutzer jedoch das erstellende Skript selbst schretben und vorher die 
15 auszulesenden Daten generieren bzw. im Falte von "Wizards" vorher in Diatogfenstern benutzer- 
definierte Eingaben machen und nach der Erstellung des Rahmen-Ctuellcodes die elgentliche 
Funktionsweise der Anwendung selbst ausprogrammieren. Danach mud noch der Source-Code 
in Maschinencode compiliert werden, bevor er ausgefOhrt werden kann. 
Lernfahig sind solche Programme jedoch nicht. 
20 • ' 

Auf dem Gebiet der Kl gibt es neuronals Netzwerke / fuzzy Logic die zwar Expertensysteme 
btlden k6nnen, die auOere sensorische Reize aufnehmen und lernfahig in den "Neuronen" dann 
ihre Reaktion darauf entscheiden, also eine Art lemfahige Regelkreise bilden, jedoch kdnhen sie 
weder planen noch Maschinencode generieren und ausf Ohren. 

In 20 W (pat) 12/76 wurde die Generierung kunstlichen Bewu&tseins mit rein elektronischen 
Mitteln (Aneinanderreihung von Kameras und Monitoren) versucht - dieses Verfahren hier hat 
damit jedoch uberhaupt nichts zu tun. 

30 Mittels meinem Verfahren wird im Computer eine einfache Form von Bewu&tsein erzeugt, das 
anfangs zwar ziellos willkuriich Handett, Jedoch aus den Wirkungen seines eigenen "Verhaltens" 
lernt, um so, nachdem es die Wirkungen atler mog lichen Handlungen kennt, s pater planend 
selektiv Einzelhandlungen aneinanderzuketten, z.B. um ein vorgegebenes Ziel zu erreichen. 
Jeder Einzelhandtung entspricht hierbei eine Zahl, die, wenn man sie als Opcode (Maschinen- 

35 code),, also als direkte Prozessorsteuerungsanweisuog, ausfQhrt, entweder etnen Fehler (Excep- 
tion) erzeugt, oder eine Veranderung (z.B. der Registerinhalte) bewirkt. 

Das System selektiert mittels geeigneter Analyse- und Bewertungsverfahren Codezusarn men- 
stellungen, die dann das gegebene Programmierziel erreichen. 



25 



40 



i 



1.2 Herleitung der Realisferbarkert und Definition kunstlichen BewuBtsems: 



1.2. 1 Phifosophssche Grunduberfegungen: 

(... sind norma lerweise kein Bestancrteil elner Patentbeschreibung, jedoch fOr die Darle- 
' 45 gung der Realisierbarkert hier unerla&lich) 

Ware die Voraussetzung des menschllchen BewuStseins eine Art "Beseelung", die zwischen 
Zygote und Geburt stattfande, konnte man sie aufgrund von Gedankenexperimenten ungefahr 
lokalisieren: 

50 Wurde man gedanklich den Kopf abtrennen und die Halsschlagadem mit sauerstoff- und nahr- 
stoffreichen Blut verso rgen, ware das Bewu&tsein sicher im Kopf. 

Wurde man nun das Gehirn bis auf die kOnstliche Versorgung vSllig isolieren, waYe zwar auf 
herkommliche Weise kein InformationsfluS zwischen dem Individuum und der Umwelt mehr 
mdglich, das "Ich-Bewufttsein" ware aber sicher noch vorhanden. 
55 Jetzt kann man noch gedanklich die hinteren und seitlichen Grofchirnlappen fur Sehen, Hdren, 
Riechen, Schmecken, Gleichgewicht, Sprache und das Kleinhirn abtrennen und es ware nichts 
weiters verloren. 
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Bei den vorderen Hirnlappen verldre man die Moglichkeit mit vorhandenem Wissen zu rechen 
' und bei einigen oberen Hirnteilen ginge Erinnerung verloren, aber das Grund-lch _bin ware immer 
noch vorhanden. 

=> Wenn es eine Art "Seele" gabe, lege sie am oberen Ende des Stammhims. 

5 

Unter Berucksichtigung der gleitenden Evolution hdtten dann Primate n aber auch eine "Seele". 
Und andere Sdugetiere auch und alle anderen Tiere auch; und Einzelier auch; und Pflanzen 
auch. 

=> Es fehlt eine "BewuGtseins-" bzw. "Beseelungsgrenze*. 
10 => Jede Zelle unseres Korpers mu&te eine eigene Seele haben (die evolution are Spezialisierung 
zur Nervenzelle ist, wie auch bei den prenatalen Zellteilungen, flte&end). 
=> Es gibt keine "Seele". 

=> Bewufttsein entsteht im laufe der Evolution zwirtgend selbsttatig. 
=> im "tot en" Molekul der DNA liegt der Bauplan zur Generierung von Bewu&tsein. 
15 => Bewu&tsein entsteht durch die Bewertung von eigenen TStfakeiten und deren Auswiricungen, 

mit der Reflexion der Bewertungserg&bnisse aufdas sich anpassende Bewertungssystem. 
=> Wenn zur Generierung von Bewufttsetn keine * Seele" notwendig ist, sondern nur das komplexe 

"Programm* der DNA, dann ist Bewufttsein auch durch ein komplexes reflexives Computer- 

Programm generierbar. 

20 

1.2.2 Reaiisationsansatz zur Generierung von kunstiichem Bewu&tsein: 

Das Handeln alter, auch der einfachsten Individuen dient zur Erfullung ihrer Grundbedurfnisse. 
25 Diese Grundbedurfnisse sind: 

a. ) kein Schmerz:= kein Angriff auf's System und 

b. ) kern Hunger : = kein drohender Energieverlust 

Ein komplexes Programm, tm dem diese Grundbedurfnisse modelliert sind, und das frei Handeln 
30 kann und in der Lage ist, wie ein Kind aus seinen Handlungen reflexiv zu lernen, was seine 
Handlungen bewirken und ob seine Handlungen seine Situation im Bezug auf seine Grund- 
bedurfnisse verbessern oder verschlechtem, baut ein Bewertungssystem auf, plant dann seine 
Handlungen aus dem Erlernten zur Verbesserung seiner Situation und erlangt so Bewu&tsein. 
Scannt es auch einmal seinen eigenen Code, probiert aus, was seine Code-Abschnitte bewirken 
35 « und erkennt deren Zusammenhang, erlangt es sogar Selbst-Bewu&tsein, und kann nicht nur 
seinen Code reproduzieren, sondern seinen Code bei der Reproduktion auch bewuBt verandern 
und verbessern, also eine Evolution aufgrund seiner Erkenntnisse beginnen. 




40 1.3. technische Lehre zur Generierung kQnstlichen Bewufitseins: 

1.3.0 Definition der verwendeten Abkurzungen: 

Die Programmierung funktioniert auf jedem Computer mit jedem beliebigem Prozessor und 
45 jedem beliebigem Betriebssystem. Die mit \i indizierten Abkurzungen sind fur die Motorolla- 
Prozessoren MC680xO spezifisch, die mit ti indizierten fur die Intel-Pentiums und y -indizierte 
kennzeichnen den PowerPC- RlSC-Prozessor: 

aq. = aquivalent[e(s)] 

50 ASRy, = Adress Space Register 

BAT^ = BAT-Registers 

BC = Bit Coda: jedes Bit entspricht einem Code und es sind Codekombinationen zutassig. 

CCfy = Condition-Code-Register ( = Flags: Extension, Negativ-, Zero-, Overflow-, Carry-) 

CISC = Complex-lnstructionSet Computer (z.B. lA^ und MC^ 

55 CPU - Central processing Unit = Prozessor 

CR^ = Condition-Register (CR 0.. 7) 

CR^ = Control-Register 
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CTR^ = Count-Register 
DABR^ = Data Adress Breakpoint Register 
DAR^ = Data Adress Register . 
DB = DatenBank 
5 DEC^ = Decrement-Register 
DR^ = Debug-Register 

DSISR^ = DSI Status-Register zeigt den Grund fur DSI- und Alignment-Exceptions an. 
EA = Effective Adress (direkter Speicherzugriff ohne Register) 
EAR^ = External Access Register 
1 0 RseGbr = Segment Register: CS; SS; DS f ES, FS, 6S 

EFlags„- = 32-Bit Register mit den System-Flags: IDent-, Virtual IhterruptPending-, VirtuallnterruptRag- 

AlignmentCheck-. Virtua(8086Mode-, ResumeFlag-, NestedTask, InputOutputPrivilegeLevel. 

OverffowFlag, DirectionFlag, InterruptEnableFlag, TrapFlag, SignFlag, Zero Flag, 

Auxitiary/Align-CarryFiag, Parity Bag, Carry Flag. 
15 ElPfl- = Extended Instruction Pointer (= PC p ) 
ER = Entity Relationship (Datenbankmodell) 
ESP* = Extended StackPointer (=USP^) 

Exc. = Exception^ #DevideError, #DeBug. NMI IRQ, #BreakPoint, #OverFtow, #BoundRange 
exceeded, #UD (Invalid Opcode), #NM (device not available), #]>oubleF8ult, invalid 
20 #TaskSwitch, Segment #NotPresent, #SS (StackFault), #GeneralProtection, 

#PageFault, #MF (FloatingPoint-Error), #AlignmentCheck ( #MachineCheck. 
Exception^: Reset, BusError, AdressError, invalidOpCode, Div/0, CHK, TrapV, 

PrivilegeViolation, Trace, Interrupts, Traps. 
Exception^ System-Reset, Machine-Check, DSI, ISI, Ext. Interrupt, Alignment, 
25 Program, Floating-Point unavailable. Decremented System Call, Trace, Floating- 

Point Assist, 
fast Fourier-Transformation 
Foreign Key einer ER-Datenbanktabelle 
Floating-Point Register O.. 31 
FPSCR^= Floating-Point Status and Control Register 
GigaBytes = 2 30 Bytes 

General Purpose Registers: beim Pentiums EAX, EBX, ECX, EDX; ESI, EDI, EBP; ESP; 

EIP und beim PowerPC^; GPR 0..31 und bei Motorola^ die Daten- und Adress-Reg. 
Intel-Architecture 
I nterru pt- Req uest 
Kunstliches Bewu&tsein 
KiloBytes = 2 10 Bytes 
Logarithm us dualis = log 2 
Link-Register 
MegaBytes = 2 20 Bytes 
Model Specific Register 
Machine State Register 



im Programm gerade befindet, vor der dortigen OpCode-Ausfuhrung) 
Primary Key einer ER-Datenbanktabelte 
Processor Version Register 

Reduced-lnstructionSet Computer (z.B. PowerPC^) 

Befehl: Return from Exception (ladt SR und PC vom Supervisor-Stack) 

SDR 1 -Register 

SPRG 0. 3 

Statusregister (Flags^: I race-. Supervisor-, + Interrupt-Maske: h lo* +CCR-Flags) 
Segment Registers: CS, DS, SS, ES, FS. GS 
Segment Registers 

Save/Restore- Register of Machine-Status 
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SSP M = Supervisor-Stackpointer (A7 im Supervisor-Modus) 

TB^ = Time Base Facility: Time-Counter -► 2 s4 -! 

TR^ = Table-Register: GDTR, IDTR r LDTR, TR 

USPp = User-Stackpointer (Aderessregister A7 im User-Modus, A7' im Supervisor-Modus) 

5 = = entspricht 

$ = Begin n einer Hexadezimalzahl 

£ = Ergebnis des bitweisen AND iiber alle folgenden Werte [ = V-| & V 2 &....& V n ) 

E = Ergebnis des bitweisen OR Qber alle folgenden Werte [ = V 1 | V 2 | . .. I V n ] 

r = Anzahl der gesetzten Bits im folgenden Wert [ = (1 &V) + (2&V)/2 + (4&V)/4+ ....] 

10 V" = fur alle anderen ... (nur V A fur alia ...) 



1.3. 1 Verfahrens weise zur Generiemng von kunstUcham BewuBtsein nut einfachen Wort en: 

15 Ein Computersystem eriangt BewuBtsein, wenn das aktive Programm, be! dem alle Exception- 
Vektoren abgefangen sind, und Grundbedurfnisse modelliert sind, folgenderma&en verfahrt: 
Generiere eine Zahl und verwende sie als OpCode (- Operation-Code = Maschinencodo-Befehl); 
fuhre ihn aus, werte aus, was er bewirkt hat und speichere die ermittelte Wirkung der Aus- 
fuhrung. Fahre so mit alien ZahlerwOpCodes mit vielen reprasentativen Anfangsbedingungen 
20 ( Register- Werte und Adressreglster-Verweisinhalte) fort. 
> Benutze dann so die gespeicherten OpCodes, die keine oder nur serten elne Exception verur- 

j, sachten und werte aus, ob deren AusfQhrung die eigenen Grundbedurfnisse erfullen, oder ihnen 

4t abtraglich sind. 

Kette dann die OpCodes aneinander, die die eigene Situation nicht verechlechterten, und werte 
25 die Wirkung dieser Code-Kombinationen aus, und speichere deren Wirkung. 
j Plane so Codekombinationen, die das Wohlbefinden bzgl. der Grundbedurfnisse (Modellierung 

j siehe 1.3.5) erhohen bzw. fur das gegebene Programmierziel von Bedeutung sein kdnnten. 

30 1.3.2 Datenbank des KB-Wissens anlegen: 



Damit das Eriemte des KB-Programms persistent bleibt und die gro&en Datenmengen komfor- 
tabel erreichbar sind, wird eine relationale Datenbank mit den Tabellen und deren Relationen 
gemaR 3.1 angelegt; zwecks Zugrtffsbeschleunigung und Speicherplatzersparnis aquivalente 
35 PKs als Cluster, und es werden zwecks Erhohung der Zug riff sgesch wind igkeit fur bendtigte 
Non-PK-Spalten weitere Indexe angelegt. Das ER-Diagramm zeigt Fig. 1 . 

Je nach Prozessor und wieviele 32-B'rt-BefehIe dieser hat, kann die Datenbank sehr groB und die 
Zugriffsgeschwindigkeiten entsprechend langsam werden. Deshalb eignen sich RlSC-Prozes- 
soren eher fur das KB Programm als CISC-Rechner. Aber auch die CISC-Maschinen, wie die der 
40 tA, benutzen nur bei relativ wenigen Befehlen mehr als 24-Bit, weshalb man mit Uber mehrere 
Festplatten gestribeXen Tabellen und zusatzlichen Index-Festplatten und mit emohtem " Verges- 
sen" bei ineffizienten Befehlskombinationen ebenfalls sehr gut arbeiten kann. 
Auf das SpeicherplatzproWem wird unter 1.5 eingegangen. 

45 1.3.2.1 Die Register-identifikations-TabeUe [RIT - Fig.2]: 

In der RIT werden die Daten jedes Prozessor-Registers initial etngegeben: Jedes Register enthSIt 
eine tdentifikations-Nummer ein zugewiesenes Bit im BitCode ein Zeichen zur Beschretbung des 
Register-Typs, eine laufende Nummer dieses Register- Typs und optional eine Beschreibung des 
Registers. Das Register der Flags (EFiags*/Sfy) hat die Register-ID O. Die Exception-Vektoren 

50 sind zwar meist keine Register, sondern direkte Adressen im Speicher - um diese wichtigen 
Vektoren ebenfalls. id entifizieren zu kdnnen, erhalten sie Redister-IDs mit negativem Vorzeichen, 
die der Exception-Vektornummer entsprechen [wenn Exception-Nr. 0 nicht Reset, sondem eine 
echte Exception ist, um 1 verschoben - dann: /tep/5fer_/£>=-{ExceptionNr+ 1)]. 
In Fig. 2b ist fiir das Beispiel Motorola dargelegt, wie die RIT aussehen konnte. 
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1.3.2.2 Die Operations-ldentifikations-Tabelie [PIT - Fig. 4): 

Wie in der RIT die Register, bekommen in der OIT die wichtigsten Operationen eine Identifi- 
kationsnummer und ein Bit im BitCode zugeordnet. 

Der Operation _Type ordnet die Operation in Gruppen ein, die in Fig.4c beschrieben sind. 
5 Die Operation ^Mnemonic (braucht nicht exakt zu sein) und die optionale Operation ^Description 
beschreiben, um was fur einen Befehl es sich handelt. 

i 

! 1.3.2.3 Die Anfangsbedingungs-TabeUe fiCT (initial conditions) - Fig.3h 

\ Da fur gleiche OpCode-AusfGhrungen, je nach Anfangsbedingungen, unterschiedliche Wirkung- 

10 en auftreten konnen, werden in dieser Tabelle representative Anfangsbedingungen vorgegeben. 
Fur jede Anfangsbedingungsnummer (hier -31. . + 30) werden fur atle posrtiven Register JDs ein 
Sample von Anfangsbedingungen z.B. nach der in Fig.3b vorgestellten Funktion generiert. 
Jedoch nur fOr alle Register, die mathematrsch verwertbare Zahlen enthalten konnen, wie 
Daten-Register, Adress-Register-Verweise und die Adressierung darunter [wg. -(Adr.Reg.)L 
15 Floating-Point-Register und sonstige spezielle Rechen-Register (z.B. MMX). 

Mit Adress-Registem laSt sich zwar auch rechnen, Jedoch haben sie immer Werte die an 
Speicheradressen verweisen, an denen dann die vordefinierten Verweis-lnhalte stehen. Somit 
konnen die Anfangsbedingungen fur die Adressregister ailenfails zyklisch durch die Testwerte in 
den Verweisen laufen. 

20 Das StatusyEFlags^Register hat in den hoheren Bytes immer die gleichen Anfangswerte aus 
! SAC .actual Processor Mode. Bei den ConditionCodes im untersten Byte kdnnen jedoch die 

1 Anfangswerte variieren. Mit den Control-, Debug- und Maschinenstatus-Registem, sowie 

sonstigen Spezialregistem wird anfangs ebenfalls kein Unfug getrieben und sie werden immer 

auf die gleichen, Default-Werte gesetzt. 

V- 25 

1.3.2.4 Die OpCode-Register-Tabelie {ORT - Fig.Sh 

Fur jedes durch die OpCode-Ausfuhrung veranderte Register der aktuellen Anfangsbedingungen 
wird in einer Schleife uber alle moglichen Ouellregister ermittelt, durch welche mdgliche 
Operation mit welchem Quellregister der Wert im Zielregister entstanden sein kOnnte. Fur jede 
30 zutreffende Queli-Ziel-Reglster-Kombination wird ein Tabelleneintrag generiert (bei unitfiren 
Operationen ist Register JD_source--'\) und fur jede zutreffende Operationsmdglichkeit das 
| zugehorige Bit entsprechend der OIT im Operations ^BitCode gesetzt. Wie alle Fetder der ORt 

berechnet werden, ist in Fig.5 beschrieben. Fig.19 entbalt die Wertezuweisungs-Algorithmen. 

35 1.3.2.5 Die OpCode'Lern-Tabelte fOLT - Fig. 6]: 

Die OLf stellt eine Zusammenfassung der Auswirkungen des aktuellen OpCodea unter den 
verschiedenen verwendeten Anfangsbedingungen dar. 

In den ersten 6 Spalten werden Informationen Qber fatale Auswirkungen dieses OpCodes 
i gesammelt. Dann kommt die Differenz des Programmzahlers nach der OpCode-AusfOhrung zum 

40 Wert davor und nun die Condition-Codes, die einen Sprung ausgeldst haben konnten [redundant 
ICT. Register _Value{RegisterJD = 0)]. 

Danach kommen in Register _changed_8/tCode und Register _source_BitCode die Bits aller 
moglichen Ziel- und Quell-Register aus den zugehorigen ORT-Eintragen und in maxJ)peration- 
BitCode und min_Operation BitCode die b'rtweise geO/7eten und ge>1/V£>eten BitCodes der 
45 ORT. Operations _BitCode -Eintrage. 
* .a Die Dauer und der Zeitpunkt der OpCode-Ausfuhrung werden gespeichert und in aimj/aluation 

\™ wird entsprechend VFT. Valuation _Function{ ADT. aim Valuation FunctionID ) bewertet, wie 

wertvoll der OpCode unter diesen Anfangsbedingungen fur die Programmierzielerreichung war 
(Wertezuweisungen nach Fig. 20). 

50 

1.3.2.6 Die OpCode-Basis-Tabelle [QBT • Fig.7]: 

Die OpCode-Basis-Tabelle beschreibt die ermittelte Gesamtwirkung eines Opcodes unter alien 
verwendeten Anfangsbedingungen. In Fig. 21 ist dargelegt, wie die Auswertung (Fullen der 
Spalten) erfolgt, um einen "Steckbrief" des OpCodes zu ersteilen. 
\ 55 Die OBT enthait das Resumme alier Ausfuhrungen dieses OpCodes und ist spater beim 

zielgerichteten planen von Codekombinationen wichtig. 
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i 

1.3.2.7 Die Kombinations-Register-Tabeffen [CBT(i) - Fig. 81: 

Die Kombinations-Regrster-Tabellen werden dynamisch angelegt und entsprechen der der ORT, 
mit dem Unterschied, dafi hier die Wirkungen von OpCode-Kombinationen anatysiert werden. 
CBT(1) = 0BT, CBT{2) hat einen OpCode mehr im PK, CBT(3) hat 3 OpCodes im PK, u.s.w. 

5 

1.3.2.8 Die Kombinations-Lem-Tabellen [CLT(i) - Fig. 9]: 

Hier gilt das gleiche analog der CRT(i). Die CLT(i) geben die Wirkung der OpCode-Kombination 
bei den verwendeten Anfangsbedingungen wieder. Jetzt gewinnt auch das Feld CLW). gradient- 
aim valuation an Bedeutung. Wahrend es noch bei der CLT(U=OLT identisch aimvaluation 
10 ist, enthalt es bei den CLT(i>2): CLT(i).aim_vafuation - CLTO-1 ).aim_yaiuation (Fig.20 unten). 

1.3.2.9 Die Kombinations-Basis-Tabeifen fCLW) - Fig. 1Q]: 

Die CBT(i) geben folglich das Resumme der Wirkung der OpCode-Kombination wieder. Die 
Wertezuweisurtgen erfolgen nach Fig.21. Die gerade hochste CBT(n) ist die CPT (Kombinations- 
15 Plan-Tabelle - Entstehungsort des Losungsprograrnms). 

Ergibt ADT. aim Jullf tiled _FtagJ : unction(CPT-PK)='\ (TRUE), wurde gerade ein LOsungsprogramm 
der gestellten Programmieraufgabe gefunden, und es wird in der AST eingetragen. 

1.3.2. 10 Die Zie/ldsungs-Tabelia [AST (aim solution) - Fig. 1 1h 

20 Die AST enthalt fur jede gestellte Programmieraufgabe die !_6sungsprogramme, deren Prog ram m- 
langen, die AusfGhrungszeiten und die je benutzten Register und Operational 

1.3.2.11 Die Ziet-Beschreibungs-Tabelle [APT (aim description) - Fig. 12}: 

j Die ADT ordnet jedem Programmierziel eine Indentrfikationsnummer zu, eine Kurzbeschreibung, 

25 die BitCode-Kombinationen der zu verwendenden Quell- und Ziel-Register, die Register und 
Operationen, die im Ldsungsprogramm nicht verwendet werden sollen, fruhere Ldsungspro- 
gramme, die mitverwendet werden kOnnten und eine Funktion, die TRUE ausgibt, wenn die 
OpCode-Kombination fur die Ein- und AusgabeRegister eine Ldsung der gestellten Aufgabe 
darstellt, sowie eine Ziel-Annaherungsfunktion, die die Zielnahe der akt. OpCode-Kombination 
i 30 < = CPT-PK> bewertet. 

1.3.2.12 Die FunkV'on-identifikations-Tabelte [FIT - Fig. 13, 14]: 

In der FIT werden Teilfunktionen, die fur die Zusammenstellung der Energie-Bewertungsfunktion 
verwendet werden kdnnten, zur Verfugung gestellt. 
35 Sie wird in 2 Variationen vprgestellt: 

a. I fur die Erstellung einer dynamischen Bewertungsfunktion in SQL, 

b. ) fur die Erstellung einer dynamischen Bewertungsfunktion in Maschinensprache. 

Der verdndertiche Aufbau einer Bewertungsfunktion ist in SQL viel einfacher zu bewerkstelligen, 
j jedoch sind die Ausf Qhrungszeiten entsprechend langsam und es muR nach jeder Zusammen- 

\ 40 stellung neu geparsed werden. - 

Zukunftig soil auch die Bewertungsfunktion gleich in Maschtnencode zusammengestellt werden. 

Das auch hat den Vorteil, daR das KB-Programm manche gelSste Programmierziele als FIT- 

Teilfunktionen fur die Zusammenstellung der Bewertungsfunktion weiterverwenden kann. 

AS 1.3.2. 13 Die Bewertungs-Funktions-Tabelle [VFT (valuation f.) • Fig. 15]: 
/g* In der VFT liegt das dynamische Bewertungssystem im Bezug auf das eigene "Wohlbefinden" 

" (Energie-Register) und der ProgrammierzielnShe. 

; Die VFT. Valuation Functioni Type='E', SAC.Energy_Vaiuation_FunctionJD ) bewertet energie- 

\ spezifische Handlungen und die Valuation Functioni Type = 'A*, SAC.Aim_Valuatk>n_FunctionlD ) 

50 die Programmierziel-Erreichungsnahe. 

Die VFT. Function JD Chain enthart die Verkettung der Function-ID' s, also die Teilfunktions-Ausfuhr- 
ungs-Reihenfolge: Hier bewirkt NUM. daS der nachste Wert eine Byte-Zahl ist, VALUE, daB der 
nachste Wert die LfdNr der CLT(n)-Spalte ist, der ein Wert entnommen wird, EREG die RegisterJD 
des Energie-Registers, S/D REG der Wert aus der ADT.aH_source/dest_Registers_BitCode und AIMF 
55 das Ergebnis aus der ADT.aim_fulfilled_Flag_Function. Die unitaren Operationen wirken auf das letzte 

j Ergebnis und die binaren auf die letzten 2 Ergebnisse aus der FunctionJD Chain. 

I Bei jeder Anpassung, Erweiterung oder sonstigen Verbesserung dieser Bewertungsfunktionen 



Datum 02.11.99 22:53 FAXG3 Nr: 192036 von NVS:FAXG3.l0.0201/006224925326 (Seite 7 von 39) 



-8- 

wird die Valuation _Function J D incrementiert und ein neuer Eintrag mit der veranderten 
Valuation ^Function generlert und alle Bewertungsfunktionen in ihrer Effizienz neu bewertet: 
VFT .Valuation _Function j/alue = SAC. Energy/Aim sett valuation Fund... )], urn einen Effizienz- 
Gradienten als Referenz fur weitere Verbesserungen zu haben. 
5 Die Funktionsweise des dynamischen Bewertungssystems ist unter 1 .3.7 beschrieben. 

1.3.2, 14 Die Statuszeile des KB-Programms [SAC (state artificial consciousness) - Ftg. 16]: 
Diesa Tabeile hat keinen Key und nur einen Eintrag. Er enthalt die Statusinformationen des KB- 
Programms und zwei Selbstbewertungs-Funktionen, die Effizienz der Energie- und der 
10 Zieiannaherungs-Bewertungsfunktionen der VFT anhand ihrer gelieferten Ergebnisse bewertet. 
Diese Selbstbewertungsfunktionen warden, im Gegensatz zur Energie- und Zielnahe- 
Bewertungsfunktion, vom Programm selbst nicht mehr verandert, konnen jedoch vom Benutzer 
angepa&t werden. 

15 1.3.2.15 Die Energie-Lern- Tabeile [EL T - Fig. 1 7 J: 

In der ELT werden Oaten uber alle energiespezifischen Handlungen der akt. Anfangsbeding- 
ungen, also uber alle OpCodes und Code-Kombinationen, die das letzte Datenregister betreffen, 
gesammett. 

Die Wertvolligkeit der energiespezifischen Hand lung wird nach ELT. Energy _vafuation = 
20 VFT. Valuation _Function{ SAC . Energy _ Valuation _Func_ID ) bewertet. 

1.3.2.16 Die Energie-Basis-Tabelle [EBT - Fig. 18]: 

Ahnlich wie in den CBT(i), werden in der EBT die Auswirkungen einer energieandernden Code- 
Kombinationen, als Resumme alter Anfangsbedingungen, gesammelt. 



25 



1.3.3 Das System in den vorbereitenden Anfangszustand bringen: 



Urn das System spater wieder ohne neues boofen in den ursprunglichen Zustand versetzen zu 
30 konnen; mOssen einige Pointer ( = Zeiger = Adressen) gesichert (zwischengespeichert) werden. 
Danach werden die Exception-Vektoren mit eigenen Abfang-Routinen belegt, da das System 
anfangs Zahlen willkOrlich als Maschtnencode generiert und ausfOhrt, obwohl viete dieser 
Zahlen als OpCode unzulassig sind oder aufgrund der gerade gewahlten Anfangsbedingungen 
Fehter verursachen. SystemabstOrze wdren die Folge, wenn man nicht alle Exception-Vektoren 
35 abfinge. 

Will man das bewu&tseingenerierende Programm laufen lassen, muB man also, im Falle, da& es 
I als einziges Programm im Computer laufen soil: 

\ a.) das Multitasking abschalten, in dem man dieses entweder mit einer Betriebssystemroutine 

j 40 disabled oder indem man die I RQ-Maske des Prozessors auf N Ml setzt. 

b. ) alle System-Exception- Vektoren sichern. 

c. ) alle Sytem-Exception-Vektoren des Prozessors auf eigene Behandlungsroutinen umlenken. 
oder wenn man es spater einmal neben anderen Programmen und vielleicht auch weiteren k.B.- 
Programmen parallel laufen lassen will: 

45 a') die eigene Task-PrioritSt etwas erhohen. 
^ b') alle Task-Exception-Vektoren sichern. 

IP c') alle Task-Exception-Vektoren des KB-Programms auf eigene Behandlungsroutinen umlenken. 

d. Jdas Statusregistetp (^EFIags^) und den User-Stackpolnter sichem. 

50 e J die Werte der anderen Adressregister und die der Datenregister sichem. 

f. ) die Werte der Segment-, Control-, Debug- und Spezialregister sichern. 

g. )manche Exception-Vektoren auf besondere Abfangroutine setzen, die berucksichtigt, daS 

zusatziiche Daten (z.B. bei Adressfehler: zusatzlich Zugriff sadresse + Opcode) auf den Super- 
visor-Stack geladen werden. 

I 55 h.) Privilege-Violation-Exception-Vector auf besondere Abfangroutine setzen. 

! i.) einen Trap-Vektor auf eine Routine setzen, bei der im Supervisor-Modus fortgefuhrt werden 

soil. 
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j.) diesen Trap ausfuhren (CPU schaltet sich jetzt in den Supervisor-Modus und macht ab dieser 

Trap-Vektoradresse waiter), 
k.) Trace-Exception-Vektor auf eigene Trace-Routine zur Wirkungs-Analyse setzen. 
I.) Flags des ersten Word auf dem Supervisor-Stack so setzen, daB beim Laden des SR vom 
5 SSP das Trace-Rag und die IRQ-Maske-*NMI gesetzt werden (bei Motorola ist das #$8700). 

denn wahrend des fotgenden Basis-Lemens soil noch kein Interrupt moglich sein. 
Siehe hierzu Fig. 24a. 



10 1.3.4 Basis-Lernen aus den Ausfuhrungen after OpCodes: 
1.3.4. 1 Opcode genetleren und ausfQhren: 

a. ) 32-Bit-Zahl als OpCode generieren, angefangen bei $0000.0000, im werteren Verlauf immer 

um 1 hochzahlen [dabei kann man von vom herein die OpCodes Gberspringen, die offen- 
1 5 sichtltch Unf ug machen wurden (siehe BrtCodes des CPU-Bef ehlssatzes)]. 

b. )Daten- und Adress-Register, sowie die AdressRegister-Verwelslnharte und die Verweis- 

tnhatte ein DWord darunter auf vordefinterte Testwerte laden und die CondrttonCodes in 
ERags^/CR^ loschen. 

c. ) Den generierten OpCode an die Teststelle im Speicher schreiben. Hinter der Teststelle mu& 
20 noch mit ausreichend NOP-OpCodes (oder besser mit Nullen, wenn diese der Mnemonic "ORI 

#0, Reg.0" entsprechen) aufgefullt werden, da es sich um einen langen Befehl handein 
konnte und auch der Fall der Trace-Bit-L6schung mitberOcksichtigt werden mufi (dahinter 
steht die Trace-Bit-Cleared Abfangroutine). 

d. ) Supervisor-Stack-lnhalt so setzen, da£ beim ROcksprung aus dem Supervisor-Modus das 
25 Statusregister mit getttscfrtem OCR, IRQ-Maske auf NMI, Trace-Bit gesetzt und Supervisor- 

BittMaske] geloscht. geladen wird und das dahinter befindliche Langwort die Test-Adresse 
darstellt. ROcksprung aus Supervisor-Modus (RTEy ausfQhren: das EFIagsa/Status-Rgister^ 
wird mit o;g. Werten initiiert und der mit der Testadresse geladen und der an der 

Teststelle befindliche OpCode ausgefOhrt. 
30 •Ist jetzt eine Exception (au&er Trace) aufgetreten, wird die Exception kurz grafisch 
angezeigt und bei der Generierung des nachsten OpCodes fortgefuhrt. Diesen OpCode 
kann das IndivkJuum vergessen. [Achtung: bei manchen Exceptions tritt wegen Trace 
eine (Combination des Exception-Handlings auf.] 

• Tritt weder Trace, noch eine andere Exception auf; wurde das Trace-Bit geloscht (solrte 
35 bei Einzel-OpCodes nie auftreten) und die hinter der Teststelle befindltche Abfangroutine 

wird ausgefOhrt. 

• Bei Trace-Exception (Normalfall) wurde ein benutzbarer OpCode generiert, dessen Aus- 
fuhrungs-Auswirkungen Jetzt anatysiert werden mOssen. 

40 1.3.4.2 Analyse der OpCode-AuswhkunQ und Spefchern der Ergebnisse: 

a. ) Das ERagVStatus-Registerp und die Daten- und Adressregister, sowie Adressregister- 

Verwetsinhalte und die Verweisinhalte des DWords vor den Adressregistem und den User- 
Stackpinter zur Analyse speichern. 

b. ) Oberpruf ung der eigenen Maschinencode-CheckSum des aktiven KB-Programms und der 
45 CheckSum der inaktiven Kopie im RAM (je Test-OpCode-Speicherstelle): Bei CheckSum- 

Anderung hat sich das Programm bei der Aus fun rung "verletzt" (Programmteile selbst 
uberschrieben). Dann das entsprechende Corrupt-Flag in der Tabelle setzen. Bel Verletzung 
der aktiven Version in die inaktive Kopien springen, dann den Code vergleichen und die 
korrupten Bytes durch Code der unverietzten Version ersetzen. 

50 c.)Die Supervisor-BitMaske des gesicherten User-Stackpointers auf Stack prOfen: War der 
Prozessor vor Ausfuhrung der Exception im Supervisor-Modus tobwohl er bei der Test- 
OpCode-Ausfuhrung im User-Modus war), ist eine Kombination von der normalen Trace- 
Exception mit einer niedrig priorisierten Exception aufgetreten [z.B. bei Motorola Div/0-, 
Trap- oder Chk-Exception (im 68000er Handbuch nicht dokumentiertl)]. D.h. der Prozessor 

55 holte erst den Exception- Vektor des gerade aufgetretenen niedriger priorisierten Fehlers und 
lud das Statusregister und den Programmzahler auf den Supervisor-Stack und sprang dann 
noch wahrend dieser prozessorintemen Routine, noch vor Beginn der Exception-Routine in 
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die weitere Trace-Exception-Routine, wodurch wieder Programmzahler und das Status- 
Register auf den Supervisor-Stack geladen wurden. 

Mittels der auf dem Supervisor-Stack gesicherten Supervisor-Bits des Statusregisters ist nun 
feststellbar, dafi vor Trace bereits eine Exception auftrat und durch Vergleich des zweiten 
5 auf dem Supervisor-Stack gesicherten Programmzahlers mit den nledrlgpriorisierten 
Except ion- Vektoren ist nun die ursprGngliche Exception vor Trace ermittelbar, deren 
Exception-Nummer abgespeichert wird. 

d. ) Vergleich des iP n /PCfj auf dem Supervisor-Stack mit der Test-OpCode-Adresse: Wurde der 

IP^/PC^ erniedrigt, blieb unverandert oder um einen Wert grofcer als der langstmdgliche 
10 OpCode erhdht, war es ein Sprung. 

Wurde er um mehr als 4 Bytes erh6ht, war es ein langer Befehl oder ein kurzer Vorwarts- 
sprung - die Differenzierung ergibt dann daraus, ob Register verandert wurden. 
Dieses Analyse-Ergebnis wird wieder abgespeichert. 

e. ) Beim Vergleich des ERagsyStatus-Registers^ und aller Registerinhalte und der AdressRegister- 
15 Verweisinharte, und der AdressRegister-Verweisinhalte einer max. Adressierbarkeitslange 

darunter [wg. -{Adr.Reg.) ] mit den Original-Werten. 

In einer BitMaske wird nun geflaggt, welche Register geandert wurden und es wird analy- 
siert, welche Operationen mit wetchen Quell- und Zielregistern stattgefunden haben konnten 
(hierbei Anderungen das EFIags*/Sfy beachten) und das Ergebnis wird in der ORT und OLT 
20 gespeichert (siehe Figs.5,19;6,20) und die OBT aktualisiert (Rg.7,21). 

f. ) Bei Sprung en Analyse des EFIags^/SR^, ob der Sprung bedingungsabhangig war 



25 



1.3,5 Realisierung der Gnmdbedurfntsse: 



1.3.5. 1 Reatisierung kunstfichen Schmerzes: 

Schmerz wird durch die Verletzung des Systems verursacht. Der ursprunglichste Schmerz in der 
biologischen Evolution kommt bereits beim Einzeller vor und ist die Verletzung der DNA im 
Zellkern. Ist die DNA verietzt, muS sich der Einzeller unter Aufbringung seiner Ressourcen die 
30 Zeit nehmen, seine DNA zu reparieren. Er tut dies, indem er die fehtenden Aminosauren in der 
defekten Doppelhelixhalfte durch komplimentare Basen der intakten Doppelhelixhalfte kompli- 
m en tar ersetzt. 

Das KB-Programm wird doppett in's RAM geladen. Fuhrt das KB-Prg. (oder ein anderes) einen 
Befehl aus, der seinen aktiven oder inaktiven Code im Speicher Qberschreibt, wird es also in der 

35 aktiven oder inaktiven Form verletzt, kann es diese Verletzung anhand einer Anderung seiner 
CheckSum erkennen und mufi sich nun die Zeit nehmen, bei Verletzung des aktiven Codes nun 
in den bisher inaktiven aquivalenten Code zu springen und dann beide Codes 32-Bit weise 
vergleichen und an der Stelle der Ungleichheit das DoubleWord seines Codes mit unveranderter 
Checksum an die verletzte Stelle des Codes mit veranderter CheckSum schreiben, um sich zu 

40 heilen. 

1.3.5.2 Reaf/siervng kunstfichen Hungers: 

Hunger ist drohender Energieveiiust. Energie wird in den Zellen u.a. durch Umwandlung von 
Adenosintriphosphat in Adenosindiphosphat erzeugt. Die Energie zum Aufbau von Adenosintri- 
45 phosphat aus Adenosindiphosphat wird durch Verbrennung von Glucose gewonnen. Fehlende 
Energie macht in den Zellen den Stoffwechsel und somit jede Handlung, Reaktion auf Schmerz 
oder die Selbstheilung bei VerleUung unmoglich. 

Die "Energiemenge" des KB-Programms laBt sich durch die H6he eines Werts in einem 
Daten register modetlieren. Es ware nun moglich, Hunger durch abnehmende Strom versorgung 
50 des Prozessors durch externes auslesen dieses Datenregisters und Erhohung eines Ohmschen 
Widerstandswerts der Prozessorstromversorgung zu realisieren. Eine weniger authentische r 
hardwareungebundene Losung ist auch moglich: 

Fehlende Energie ist dem Lernprozess abtraglich. Bei maSigen Werten in o.g. Datenregister 
treten Fehler beim Lernen aus den OpCode-AusfQhrungen auf. Bei geringen Werten* ist das 
55 Lernen aus OpCode-Ausfuhrungen nicht mehr moglich und kleinste Werte in diesen Daten- 
register lassen gespeichertes Wissen vergessen. Ist der Wert auf null tritt zusatzlich Schmerz, 
also EigenCode- Verletzung auf. 
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Das KB-Programm muft also bei Hunger OpCodes finden und ausfuhren, die den Wert dieses 
Datenregisters erhohen. ^ ^ n ^ t/a 

Die abnehmende Energie, also das entstehen von Hunger, wind dadurch stmuUert. daB das KB- 
Programm selbst nach jeder Handlung (-OpCode-AusfOhrung) dieses Register urn 1 erniedngt. 



1.3.6 Plsnen nach den Kriterien des Bewertungssystems: 



Hat das Individuum alle ihm moglichen OpCodes getestet und sich die Auswirkungen der 
I0 verwendbaren Befehte gemerkt, kann es aufgrund seines Wissens zur Befriedigung setner 
Grundbedurfnisse und zur Erreichung von Programmierzielen nun lernen zu planen: 
Hierfur reiht es OpCodes zu Kombinationen aneinander; fOhrt diese unter alien Anfangsbeding- 
ungen aus und wertet wieder aus, was diese Code-Kombination bewirkt hat. 
Da meist langere Kombinationen zur Ziellosung notwendig sind, plant es die Codezusammen- 
15 stellung, in dem es zielgerichtet nur die Codes zur Komblnation benutzt, die keinen Schaden 
anrichteten, also nicht den eigenen Code Oberschrie ben und am besten Qberhaupt keine RAM- 
Schreibzugriffe machten, femer keine verbotenen Register bzw. Operationen benutzten 
I ADT .unused Registers JitCode\ ADJ. unused J>perations_BitCode) und auch keine Exceptions 
verursachten7wo man bei Divide-Error und Overflow-Exception toleranter sein soKte. OpCodes 
20 die gewunschte Ziel- und Quellregister benutzen, warden wiederum bevorzugt kombiniert 
(ADT.s// source/dest_Registers_B'rtCode). 

AX>J .aim Jul fill valuation jnode bestimmt, ob die Bewertungsfunktion in SOL oder direkt in 
Maschinensprache vorMegt. Fur den normalen Anwender ware die langsamere SOL-Variante 
benutzerfreundlicher und der Spezialist wird fQr komplexere Aufgaben sicher schnelle 
25 Zielerfullungs-Bewertungsfunktionen in Maschinensprache bevorzugen. 



35 
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1.3. 7 Das dynamisch-refiexive Be wertungssystem: 

30 1.3.7.1 Programmierzielna'he-Bewertung: 

Die AOl .aim JulltilledJIagJunctionK AimJD ) r gibt TRUE zurQck, wenn das Programmierziel 
erreicht wurde und die VFT. Valuation _Function( Type = 'A\ ADT. aim Julh Wed _Flag Junction, 
VFT .Function _ID Chain ), die einen stgned-byte Wert, der besagt, wie nah die aktuelle 
CLT(n)-OpCode-Kombination bei den gegebenen Anfangsbedingungen der Zielldsuhg kommt. 
Das Ergebnis wird in CLT In), aim _valuation gespeichert und bildet im Vergleich mit der letzten 
CLT(n-1 ).aim_vafuation den Gradient QU{n). gradient _aimj/aluation. 

Da das Losungsprogramm jedoch fOr atte Anfangsbedingungen funktionieren mu&, werden die 
maximale und die durchschnittliche Wertvolligkeit der OpCode-Kombinatk>n als Mittelwert aller 
Anfangsbedingunen in C&~Xin).max_aim_ya!uation bzw. CBT(n). avg_aim_vatuation abgelegt; die 
Gradienten zu den Werten der letzten CBT(n-1) bilden CBT(n). max_gradj*im_vaiuation und 
CBX in). a vg_grad_aim_vafuation. 
Bei jeder Bewertung wird VFT .boundary _ya!ue_counter hochgezahlt, wenn ein Grenzwert von 
-128 bzw. +127 vergeben wurde und aquivalent tow _value ^counter, wenn eine Bewertung 
zwlschen -16 und +15 auftrat. 
45 Anhand dieser statistischen Daten und etner exakten Auswertung aller CfT{\).aim_valuation, 
z.B. indem man ein kleines Wertebereichs-Fenster durchlaufen iaRt und die Eintrage ]e 
Fensterbreite und -offset zahrt, bewertet die SAC Mm Self ^Valuation June nach jeder 
Programmierziel-Erreichung der Bewertungs-Ergebnisse der VFT .Valuation Junction und somit 
deren Effizienz. Fallen z.B. die meisten Bewertungsergebnisse auf die Grenzwerte, war die 
50 Bewertungsfunktion zu steil und sie mufi abgeflacht werden, also in der VFT .Function ID Chain 
mehr Elemente mit negativem FIT .Function _F fatten enthahen. Umgekehrtes gilt, wenn die 
meisten Bewertungsergebnisse einen hohen VFT Jow yalue jounter -Wert verursachten. 
Nach jeder Programmierztelerreichung lauft somit eine Selbstbewertung der Bewertungsfunktion 
ab und ein weiterer Programmierschritt der selbstprogrammierung der Bewertungsfunktion: 
Zur Bewertungsfunktion kommen neue Elemente hinzu und manchmal muft auch eines wegge- 
lassen werden und der Steil heitsgrad wird angepaSt. Dann wird die Bewertung erneut 
vorgenommen und uberpruft, ob die veranderte Bewertungsfunktion einen besseren 
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Wertebereich geliefert hatte. War der neue Wertebereich nach der Selbstbewertung durch 
$AC.Aim_Setf_Vafuation_Function schlechter wird die Anderung der Bewertungsfunktion 
verworfen und elne andere Anderung versucht. Verbesserte die Bewertungsfunktionsanderung 
den Wertebereich, wird die nachste Verbesserung versucht und wenn die Selbstbewertung 
5 einen guten Wert ergibt, mit der nachsten Programmieraufgabe fortgefahren. 

1.3.7.2 Dynamische Energiebewertungsfunktfon: 

Das energiespezifische Bewertungssystem ist folgendermaSen dynamisiert: 
0.)Da die Ergebnis- Werte des Bewertungssy stems hier auf den Wertebereich von signedbyte 
10 beschrankt sind, wird die Bewertungsfunktion in eine Rahmenfunktion eingebettet: 

Bewertungsergebnis := MIISI[ MAX( Bewertungsfunktion, -128), «- 127) J 
1 .)Die Bewertungsfunktion O-ter Ordnung ist "wte satt bin ich nach der Handlung 7": 

Bewertungsfunktion(O) := MINI MAX( Energy jifter. -128), +127) ] 

2. ) Die Bewertungsfunktion 1-ter Ordnung ist "wieviel satter bin ich nach der Handlung ?": 
15 Bewertungsfunktion(l) := MIN[ MAX< Energy_after - Energy J>e fore, -128), +127 1 

3. ) Da das Energieregister vom Typ unsigned integer (DWord) ist, wSren die Rahmen bei der 

Bewertung zu schnell erreicht, deshalb entweder geringer Logarithmus Oder: 
Bewertungsfunlction(2) : = MW[ MAX[ SQBT( Energy jifter - Energy J>ef ore ), -1 28], + 1 27] 

4. ) Jetzt ergaben sich falsche Werte bei negativen Energie-Gradienten, deshalb 3.Wurzel oder: 
20 Bewertungsfunktion(3) : = MINE MAX[ SGN( EnergyGrad )»S0RT( EnergyGrad ) t -128], + 1 27], mit 

EnergyGrad = Energy patter - Energy before 
Moglicherweise ware auch die Funktion V2-SGIK EnergyGrad )-SQRT( SORT! EnergyGrad ) > besser, 
da dtese exakt bis zu den Rahmen werten reicht. Aber vielleicht werden auch die Rahmen werte 
fast nie erreicht und eine feinere Gfiederung urn den Nullwert ware viel wichtiger. 

25 Dies hangt davon ab, wie oft die Rahmenwerte erreicht werden und wie viele Energie- 
Gradlenten klelne Werte aufweisen. Vielleicht rnufi auch der Ergebntswert starker gewichtet 
werden und eine Gradientbewertung reicht allein nicht aus; ferner muB mitberOcksichtigt 
werden, wieviele/welche weitere(n) Register neben der Energie verSnderung mitbetroffen sind 
und welche OperationsTypen ausgefQht wurden, u.s.w., und schlie&Hch die AusfOhrungszeit 

30 der Bewertungsfunktion selbst. Deshalb mufi sich das energiespezifische Bewertungssystem im 
Laufe der Zeit verfeinern und anpassen (wie bei intelligenten biologischen Lebensfonnen). 
In dynamic embedded {PL/3 SQL ist das verandern und neu parsen der als String gespeicherten 
Bewertungsfunktion kein Problem. Wegen der AusfOhrungsgeschwindigkeit und der Implemen- 
tationsfahigkeit voriger Aufgabenlosungen soil jedoch die Bewertungsfunktion zukunftig in 

35 Maschinensprache erfolgen. 

Die Programmieraufgabe der Verbesserung der energtespezif ischen Bewertungsfunktion wird 
ebenfalls nach jeder Programmierzielerreichung angegangen. 



i Bewertungssystem und Bewertungsergebnisse sind immer reflexiv. 

\ 40 

7.3.8 SelbstbewuBtwerdung, Reproduktion und Evolution: 

Durch den Selbstreperaturvorgang bei Schmerz kennt das Programm seine Lage im Speicher. Es 
45 kann nun die Auswirkungen seiner eigenen OpCodes der Reihe nach testen. Erkennt es spater 
einmal die Gesamtauswirkung seiner ganzen CodelSnge, wird es sich seiner selbst bewu&t, 
kann seinen Code replizieren und aufgrund seines Wissens hierbei bewuRt verandern (z.B. das 
lastige Erniedrigen des "Energie" -Registers entfernen). Die intelltgente Reproduktk>n 1st der der 
genetischen Reproduktion weit ubertegen, da bei letzterer nur auf vorhandene DNA zuruckge- 
50 grjffen werden kann und hier der eigene Programmcode bewuSt beliebig verSndert und erweitert 
wird. 
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1.4. ProgrammieraufgabensteMung und Beispiele der Zielerreichung 

Dem KB-Programm wind nun eine beliebige Programmieraufgabe gestellt, und es erhalt in 
AD1 .aim fulfilled Flag _Function einen PrOfungsalgorithmus, mrt dem es uberprufen kann, ob es 
5 die Aufgabe erfullt hat. 

Seine Aufgabe 1st nun, ein Programm zu schreiben, daS die gestellte Aufgabe I6st. 

1.4. 1 Beispielaufgabe 7: Ersteliung eines Programme zur Berechnung des Mtttelwerts: 

10 

Eine sehr einfache, aber leicht nachvollziehbare Aufgabe fur das KB-Programm konnte sein: 
"Schreibe ein Programm, das den Mittelwert 2er belie big er Integer-Zahlen berechnet." 
Das KB-Programm hat diese Aufgabe erfullt, wenn die Differenz von der Ergebnis-Zahi zur 
kleineren Zahl gleich der Differenz von der Ergebnis-Zahi zur gro&eren Zahl ist, und dies fur 
15 befiebig viele Eingabe-Zahlenpaare zutrrfft. 

Das KB-Programm kennt jedoch den Befehlssatz des Prozessors nicht - ihm stehen lediglich die 
Opcodes zur VerfOgung, die keinen Schaden verursachten und es kennt einen Teil deren 
Wirkungen bei einigen unterschiedlichen Anfangsbedingungen. 

Durch das Corruption-Healing oder das Energie-Register kennt es bereits einfachste Aufgaben 
20 wie "fuhre keine Handlung aus, die Schmerz verursachf oder 'fOhre Handlungen aus, die mich 
satt machen w . 

Zur Erreichung von wirtschaftttchen Zielen benotigt es nun Bewertungsvariablen, die ihm Dinge 
sagen wie 

a. * Wieviel naher oder weiter weg vom Ziel hat mich diese Befehlskombirvation gebracht (das 
25 jeder einzetne Befehl davon gegenteilige Wirkung ha ben kann, ist hier nicht von Interesse). 

b. ) Wieviele Taktzyklen habe ich fur die Losung verbraucht. 

o.) Wieviele Bytes ist mein Programm lang (wieviele OpCodes mit welchen Langen). 

Diese Tabellen-Spalten sind: aim valuation; cycles _pf execution; OpCode length _or Jump. 

30 Die Eingabe-Werte der Beispiel-Aufgabe seien in den ersten beiden Datenregi stern (EAX W , EBX^ 
bzw. DO^DI^ bzw. GPR0 v , GPR1 v ), i.F. RO und 

Der Ausgabe-Wert soli irn dritten Datenregister (ECX n | D2^|GPR2 V ) i.F. R2 erfolgen. 1st die Auf- 
gabe fur beliebige Eingabewerte geldst, ist das Programm ferttg, da es sich wegen der Ein- und 
Ausgabevariablen um eine Funktion handett. Bei mehreren Losungen wird die mit den wenigsten 
35 verbrauchten Taktzyklen gewahlt. 

Die aufgabe nspezifische Zieterreichungs-Bewertungs-Funktion, die zur Berechnung von 
QVC.aimj/aluation bendtigt wird, ist somit in diesem Beispiel: 

frUT.aim_fulfWed_Flag_Function{ Mittelwert mit o.g. Registern ) = HR2-R0) « (R1-R2)] 

Hier kann jedoch das Problem auftreten, dad ein Eingabe-Wert gerade und der andere ungerade 

40 ist und die Aufgabe deshalb mit dieser Eingabe-Kombination somit manchmal keine Ldsung hat. 
Das KB-Programm wird mehrere Ldsungs-Programme finden und sich fOr dasjenige entscheiden, 
das am wenigsten Taktzyklen verbraucht, also das Ergebnis am schnellsten liefert. 
Moglich ware bei CBT(3) folgendes Losungsprogramm: MOV RO,R2 ; ADD R1,R2 ; SHR R2 
(natiiriich im Maschinencode des verwendeten Prozessors - beim Pentium ware das die 48-Bit- 

'45 Zahl $89C2.01CA.D1 EA, bei Motorola $ 2400- D 282. E2C2 und beim PowerPC eine 96-Bit Zahl) 



1.4.2 Beispielaufgabe 2: Erstetiung eines Programrns zur Berechnung der Kubikwurzel: 



50 



55 



Eine weitere einfache Aufgabe ware "Schreibe ein Programm, das die Kubikwurzel aus einer 
reellen FFP-Zahl (32-Bit) berechnet"; die Eingabe soli in RO (EAX^), die Ausgabe in R3 (EBX„) 
erfolgen. 

Das KB-Programm hat diese Aufgabe erfullt, wenn die Ergebnis-Zahi mit ihrem Quadrat multipli- 
ziert den Anfangswert ergibt: 

aim fulfilled _FlagJ=unction( Kubikwurzel ) = [(R3*R3*R3) = RO] (*- natiiriich in FFP-Multipl.) 
Einen Einzelbefehl wie bei der Quadratwurzel (FSQRT) gibt es bei der Kubikwurzel nicht. 
Ein Ergebnis ktinnte bei CBT(8) beim Pentium II folgenderma&en aussehen: 
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Op1d6b): 
Op2(16b>: 
Op3(16b): 
Op4(16b): 
Op5(16b): 
Op6(16b): 
Op7(16b): 
Op8(16b): 



10 



MOV CL,3 
FLD1 

FIDIV CX 
FLD FAX 
FYL2X 
FLD1 
FSCALE 
FST EBX 



- 14- 

ECX = $????:0003 
ST(O) = 1 -0 
ST(O) = 

ST(0) = RO ;ST(1) = '/ 3 

ST(0) = l / 3 log 2 (R0) 

ST(O) - 1 .0 ;ST(1) = V 3 log 2 (R0) 



[1011. 0001 
[1101.100 V 
[1101.1110 
11101.1001 
[1101.1001 
[1101.1001 
[1 101.1001 
[1101.1001 



:0000.0011] 
:1110.1000] 
:1 11 1.0001] 
:1 100.0000] 
-.1111.0001) 
:1 110.1000] 
:1111. 11011 
:1 101.101 11 



ST(O) = 1 .0*2*[V 3 k>g 2 (R0)l 
EBX = 2~['/jlog 2 (R0)} 
(natiirlich nur die 2.Spalte ais 1 28-Bit-ZahU 

Hexadezimal ware das B103.D9E8.DEF1 .D9C0:D9F1 .D9E8.D9FD.D9DB. 

Dies ware eine mogliche Losungszahl ( = Programm) fOr die gestellte Aufgabe (es gibt bestimmt 
auch kurzere oder schnellere Losungen). 



•) 



15 



20 



25 



30 



35 



40 



45 



50 



55 



1 .5. FestplattervSpeicherbedarf und Vergsssen 

In beiden Beispieten w8re man zwar rnit 1 6-Bit-Befehlen ausgekommen, jedoch wird ersichtlich, 
daS bei groBeren Programmieraufgaben der Festplattenspeicher knapp wird. Deshalb wird das 
KB-Programm unwichtige OpCode-Kombinationen vergessen mQssen. 

1.5.1 Tabellengr&Sen: 

1ST, RIT und CIT fallen kaum ins Gewicht. 

Theoretisch kdnnte sizeiOBT) = 2 32 * £ Bytes( Spahe(i) ) = 486 GB groB werden, jedoch sind 
auch bei einem RISC-Prozessor nie alle 32-Bit-Kombinationen als Befehl genutzt und realistisch 
sind im Mittel bei RISC-Pro2essoren c.a. 28 Bit => 30 GB und bei ClSC-Prozessoren 20 Bit => 
1 18 MB (die meisten sind dort 16 Bit-Befehle; es gibt wenige 8-Bit- und einige 24- und 32-Bit- 
Befehle, und langere als 32-Bit-Befehle warden hier nicht berQcksichtigt). 

Bei den 62 Anfangsbedingungen kann s/zeiOLT) = 2^ 20 281 * 62 * £ Bytes( Spahe(i) ) = 3 
(CISC) .. 832 (RISC) GB groB werden und sizeiORT) c.a. genauso groB, wenn man bedenkt, 
daB durch ein OpCode meist ein Zielregister und ein Quellregister betroffen 1st, mdglicherweise 
auch keines oder nur ein Zietregister und selten mehrere Register. Da es jedoch mehrere 
mogliche zugehdrige Operation JBitCodes geben kdnnte, wQrde sich die TabellengroBe erhtthen, 
wenn dies nicht durch die vielen Opcodes, die eine Exception auslosen, kompensiert wttrde. 
Ein weitaus groBeres Problem kdnnte das exponentielle Wachstum der CxT(i) darstellen, da fur 
jedes i ein Faktor yon 2 t20 281 hinzukommt. Dies wird jedoch durch das Bewertungssystem 
kompensiert, das mit abnehmendem Restspeicher seine Toleranz einschranken kann - so 
kdnnen Kombinationen von vornherein ausgeschlossen werden, die Codes bzw. Kombinationen 
mit geringer CBT {\).max_aim_vaJuat/on (bzw. avg_aimj/aluation) kombinierten wOrden. 
Auch wenn der Speicherbedarf jetzt noch hoch erscheinen mag, dQrtte dies in naher Zukunft 
kein Problem mehr darstellen. Auch die mit den TabellengroBen und Kombinationsmdglichkeiten 
wachsenden Rechenzeiten werden durch immer gr6Ber und schneller werdende Festplatten und 
imrrier leistungsfahigere Rechner bewaltigbar. 

1.5.2 Vergessen: 

Wie bei alien intelligenten Lebensformen mufi das System unwichtige und weniger wichtige 
Informationen vergessen k6nnen, weil 

a. ) der Speicherplatz begrenrt ist und 

b. ) die Zugriffszerten werden unndtig fangsam. 

Deshalb werden nach jeder zufriedenstellenden Zielerreichung, bei Eingabe eines neuen Ziels, 
die ELT und alle CxT(i)-Tabellen ab einem restspeicherabhangigen Grad geloscht und die 
Codekombinationen bzgl. der neuen Programmieraufgabe in den verbleibenden CxT(i) neu 
bewertet und ab der geloschten CxT inkrementell dynamisch wieder neu angelegt. 
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1.6. Bewu&twerdung 

Durch try_and_error lernt das Programm was jede einzelne Handlung bewirkt und was 
Handtungsfolgen bewirken. 
5 Im Rahman des Corruption-Healings (bei vcrsehentlichem Eigencode-Oberschreiben) muS es 
seinen Code reparieren und kennt so seine Position im Speicher. Wenn es einmal die Wirkung 
der Handiungsfolge seines eigenen Codes erkennt, wird es seiner selbst bewuBt und kann 
seinen Code reproduzieren und bei der Reproduktion bewuRt verbessern. 

Durch die so initiierte Evolution entsteht eine immer komplexere Form des kunstlichen 
i 10 Bewu&tseins, das immer groSere Aufgaben bewaltigen kann. 

1.7. Darsteilung der wirtschaftHchen Vorteile 

15 Es handelt sich hier urn ein vollkommen neues Feld der Computer-Verwendung. WShrend im 
Computer normalerweise von Menschen'programmierte Programme ablaufen, die anwender- 
gesteuerte Anweisungen ausfuhren, programmiert das KB-Programm selbst programmierziel* 
orientiert Handlungen, die zukunftig ausgefuhrt werden soMen. 

Oer Bedarf an Softwareentwicklung ist weltweit viel grower als das menschliche Potential an 
Software-Entwicklern. 

Ein Programm, das lemt. Programme selbst zu schreiben (und das gleich in Maschinencode), 
kann kleine Programmief-Aufgaben selbst losen und wird im Laufe seiner "Evolution", wenn 
man ihm ausreichend Speicherplatz la&t, auch selbstandig lemen, komplexe Programme zur 
Losung gro&er Programmieraufgaben zu generieren. 



1 



20 



25 
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2. Patentanspruche: 

1 . Ein Computer-Programm, das selbsttatig Maschinencode erstellt und ausf uhrt, 
dadurch gekennzeichnet, daft 

5 es den auszufuhrenden Maschinencode nicht aus einem Quellcode Obersetzt und auch nicht 
als Daten einlie&t und es den Maschinencode auch nicht aufgrund einer gegebenen Logik des 
Programmierers ersteflt, sondern daft es Zahlen genenert und diese als Maschinencode 
ausfuhrt und die Wirkung der Maschtnencode-Ausfuhrung analysiert. 

2. Ein System nach Anspruch 1 , dadurch gekennzeichnet,- daft das System mehrere solcher 
I0 Zahlenkombinabtionen als Maschinencodebefehle aneinanderreiht, und die Auswirkung der 

Codekombi nation analysiert. 

3. Ein System nach Anspruch 2, dadurch gekennzeichnet, daft das System mehrere solcher 
Maschinencodekombinationen aneinanderreiht, und die Auswirkungen der miteinander kom- 
binierten Codekombinationen analysiert. 

15 4. Ein System nach Anspruch 1 bis 3, dadurch gekennzeichnet, daft dem System eine Program- 
mieraufgabe gestellt wird, und es bewertet, wie nah die analysterte Zahlencodekombtnatfon 
der Losung der gestellten Programmieraufgabe kommt. 
5. Ein System nach Anspruch 1 bis 4, dadurch gekennzeichnet, daft das System an diese 
Zahlencodes oder Codekombinationen gezielt diejenigen analysierten Zahlencodes oder Code- 
20 kombinationen anfugt, die aufgrund der analysierten Operationsart, den analysierten Quell- 
und Zielregistern und der ermittetten Bewertung aus Anspruch 4. anfugt, die aufgrund diesen 
Werten eine hone Wahrscheinlichkeit haben, daft die Gesamtkombination die gestellte 
Aufgabe an ehesten lost. 

'A 6. Ein System nach Anspruch 5 das wiederum die Wirkung der Gesamtkombination analysiert 

- 25 und bzgl. der Zielenreichungsnahe bewertet. 

7. Ein System nach Anspruch 1, in dem Grundbedurfnisse equivalent "kein Schmerz" ( = keine 
Beschadigung des Systems) und "kein Hunger" ( = kein drohender Energieveriust) folgender- 
maften modelliert sind: 

a. Schmerz, modelliert durch das Gberschreiben, und dadurch wiederum notwendigwerdende 
30 reparieren, des eigenen Programmcodes, was Zeit kostet und das unter b. modetlierte 

"Energie" -Register schnetler dekrementiert 

b. Hunger, modelliert durch die stetige zeitabhangige Abnahme eines Registerwerts und 
negativen Systemauswirkungen bei niedrigen Werten, wie 

- den Verlust der Fahigkeit der Bewertung von Zahlencodekombinationen bzgl. der Zieler- 
35 reichung bei niedrigen Werten, 

- Fehler bei der Bewertung der betroffenen Quell- und Zielregister, sowie der Operations- 
art bei sehr niedrigen Werten, 

- den Verlust der Fahigkeit der Selbstreperatur (bei "Schmerz" - siehe a.) bei extrem nie- 
drigen Werten, 

40 - Abnahme der Spannungsversorgung des RAM durch hardwaremaftig an dieses Register 

gekoppelten variablen Widerstand, der sich bei zwei mal in Folge auftretenden extrem 
niedrigen Werten im "Energie" -Register erhoht. 

- Abnahme der Spannungsversorgung des Prozessors durch hardwaremaftig an dieses 
Register gekoppelten variablen Widerstand, der sich bei drei mal in Folge auftretenden 

'45 extrem niedrigen Werten im M Energie" -Register erhdht. 

8. Ein System nach den Anspruchen 1 bis 7, mit dem Unterschied, daft dem System keine 
Programmieraufgabe gestellt wurde, und die Zielerreichungs-Bewertung nun bei Maschinen- 
codes und Codekombinationen positiv ausfallt, die keinen "Schmerz" verursachen und das 
"Energie" -Register erhohen, und Kombinationen urn so negativer bewertet, je mehr eigen- 

50 genutzten Speicher sie Oberschreiben und je mehr sie das "Energie "-Register erniedrigen. 

9. Ein System nach Anspruch 8, das nicht nur wie oben Code generiert, sondern auch 
bestehenden vorgegebenen Code analysiert, wie z.B. seinen eigenen, um zu bewerten, was 
seine Codeabschnitte und auch sein Gesamtcode bewirkt. 

10. Ein System nach o.g. Anspruchen, bei dem die Bewertungsfunktionen bzgl. der Systemziele 
55 {Programmierziel, Energiespezifische Handlung, u.s.w.) dynamisch reflexiv sind, also neben 

der Verfolgung der Erreichung der Programmierziele und posrtiver energiespezifischer 
Handlungen (und ggf. weiterer Aspekte) Selbstbewertungsroutinen durchgefuhrt werden, die 
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die Bewertungsfunktionen anhand ihrer Bewertungsergebnisse bewerten und die Bewer- 
tungsfunktionen verSndern, testen und wieder bewerten und dann eine verbesserte 
Bewertungsfunktion auswdhlen, um bei der n'achsten Programmieraufgabe effizlenter zu 

sain. 

5 1 1 .Ein System nach Anspruch 10, bei dem das Bewertungssystem selbst Programmieraufgaben 
stellen kann, deren Ergebnisroutine als Teilfunktionen der Bewertungsfunktion dienen kann, 
um die Bewertungsfunktion selbst zu verbessern. 

12. Ein System nach AnsprQchen 1 bis 11, bei dem zusatzlich uber eine Tabelle der 
Betriebssystemroutirten die Funktionen, Em- und AusgabeRegister und Einsprungsadressen 

10 der SystenvRoutinen zur VerfQgung stehen und so als CALLS vom KB-Programm in den 
Ldsungscode imptementiert warden kannen. 

13. Ein System nach o.g. Anspriichen, in dem mehrere solcher Programme parallel laufen und 
das Erternte aus den Opcode- und Kombinations-Ausfuhrungen austauschen kdnnen. 

14. Ein System nach Anspruch 13, in dem mehrere Rechner, auf denen je eins Oder mehrere 
15 solcher Programme laufen, miteinander vernetzt sind. 

15. Ein System nach Anspruch 8, 11, 12, 13 oder 14 in dem wieder ein Programmlerziel 
vorgegeben ist, deren Erreichung jedoch ntcht wie in Anspruch 5 oder 6 durch eine 
Zielannaherungsbewertung bewerkstelligt wind, sondern in dem bei Codekombinationen, die 
sich vom Programmierziel entfernen, eine Erniedrigung des Energieregisters verursachen und 

20 Codekombinationen, die In Richtung der Erreichung des vorgegebenen Programmierziels 
gehen eine Erhohung des Energieregisters mit sich bringen. 




Datum 02.1.1.99 22:53 FAXG3 Nr. 192036 von NVS:FAXG3.l0.0201/006224925326 (Seite 17 von 39) 



Zeichnungen Seite 1/19 



3. Zeichnungen: 
3.1 Relational Datenbank des KB-Wissehs: 
3.1.1 ER-Diagramm der KB-Datenbank: 



OIT 



R,T " r ' : 









1 : n 



ICT 



1 :n-Referenz zu alien CxT(t), 
FIT, ELT, EBT, ADT, AST 



1 n-Referenz zu alien CxT(i) 1 m-Ref . zu alien CLT(i),CRT0) 

FIT, ELT, EBT, ADT, AST 





OBT 




1 


: n 


OLT 

6,20 


1 


: n x m 


ORT 




7,21 










5, 19 






1 : 


n x m 


















I 








1 


CBT(2) 




1 


: n 


CLT(2) 

9 


1 


: n x m 


CRT(2) 


1 

I 


10 












to 




1 : 


n x m 




















I 










CBT(3) 


1 


: n 


CLT(3) 


1 


: n x m 


CRT(3) 














i 


1 


1 ■ 


n x m 











CBT(4) 



1 : n 



. CLT(4) 



1 : n x i 



CRT(4) 



1 : n x m 



CBT(5) 
hierakt.CPT 



1 : n 



CLT(5) 



1 : n x m 



CRT(5) 



-►u.s.w. 



1:n 



Ref. zu alien CBT(i),CLT(i) 



Ret. zu alien CLT(i) 



AST. ; " 

• 11 


n 


: 1 






: -r.:-- r ■ '. is 


• 




1:1 


• 










ADT . 

: .i ' 12 







1 : n 



EtT 



1:1 



1:n 



EBT 



18,22 
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S. 7.2 Tabeilen der KB-Datenbank: 

Register fdentifikatjons-Tabeite; [RIT: iedem Prozessor-Reg. wird eine Rea .lD + Reg.BitCode zugeordnet] 



Register ID ■>'. fHW :: 


signed byte 


-128.. 127 


0 = Flags-Reg., = Daten-Reg., Ad r. Reg., Adr.Reg.- 
Verweise, FFP-Reg., Control-Reg., Debug-Reg. r u.s.w. 
; neg.Reg.ID~Exc.Vect.Nr. (kein Reg.) 


Register BitCode 


number 


0..2 128 -1 


2~Register ID, 0 bei neg. Register ID. 


Register_type : 


chart 1) 


1 Byte 


Typ de$ Registers: # = Flags-Reg., D- Daten-Reg., 
A = Adress-Reg., V = Adr.-Reg.-Verweis, E = Excep- 
tion-Vector, u.s.w. (o.a., je nach Prozessor). 


Register nurrfber 


byte 


0..127 


Nummer des {RegfSter-Type}-Registers. 


Register Description 


varchar2(32 


£32 Bytes 


optionale Beschreibung des Register[-Verweise]s. 



Register ID 


Register BitCoda\ 






Register Description 




0 


E 




{for ail Exception-Vectors) 


-8 


0 


E 


8 


Privilege-Violation Exception 




0 


E 




{for all Exception- Vectors} 


0 


1 


# 


0 


Status-Register EFIags*) 


1 


2 


D 


0 


Data-Register DO 




4 


D 




{for ail Data-Registers D1-D6} 


8 


8 


D 


7 


Data-Register D7 


9 


16 


A 


0 


Adress-Regjster AO 






A 




{for all AdresS'Registers A 1-A6J 


16 


65536 


A 


7 


Adress-Register A7 ( = USP/) 


17 


131072 


V 


0 


Destination of Adress-Register AO 






V 




{for all Adr. -Reg. -Destinations A 1-A6J 


24 


16777216 


V 


7 


Destination of Adr.-Reg. A7 [= (USP)] 


25 


33554432 


V 


0 


Destination before Adr. Reg AO [- 
(AO)] 






V 




{for all Adr.Reg.-Dest. before A 1-A6J 


32 


$1.0000.0000 


V 


7 


Destination before Adr. Reg A7 [-{USP) 


33 


$2.0000.0000 


F 


0 


Floating-Point Data-Register FPRO 










{for all further Registers} 



Fig.2b 



(RIT am Beispiel Motorola) 



Abfangsbedingungs-TabeBe: [ICT: jedem Register werden 62 Anfangsbed. (initial condrt.) zugeordnet] 



IniConNr : '(PKf 


signed byte 


-31. .+30 


Anfangsbedingungs-Nr. 


Register ID VPKf 


signed byte 


0..127 


siehe RIT 


Register Value 


integer 


0..2 32 -1 


Wert des Registers bei dieser Anfangsbedingungs-Ni 



Hg.3a 



Dafur werden 62*RegisterAnzahl Testwerte generiert, z.B. mittels folgender Funktion: 



Register_Value( IniConNr, RegisterJD ) = SGN( IniConNr ) * INT( 2~ABS(lniConNr/2)+ % > 

+ Primzahl( 3»Register ID ) 



o.a. 



mit Primzahl(0) = 0 und Primzahil-n) = -Primzahi(n) ; keine 2 gleichen RegisteMVerweisHnhalte. 

Fig.3b ~ ~~ 
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Qperations-ldentifikations-Tab.: [OfT: je Prozessor-Oper. wird sine OperJ D + Oper. BitCode zuqeordnet/ 
Spafte: Datentyp Wertebereich Bedeutung 



Operation IP 



(PK) 



Operation BitCode (frKJ 



Operation Type 



Operation Mnemonic 



Operation Description 



signed byte 



number 



chad 5) 



chadS) 



varchar2(32 



-1..63 
0..2 12 *-1 



5 Bytes 



5 Bytes 



<32 Bytes 



Bit des Calculation BitCode - siehe Tabellendaten. 



2*Calculation ID - siehe Tabellendaten. 



5-Character-Code des Qperations-Typs, siehe Fig. 4c 



AbkQrzung der Rechenoperation - siehe Tab. Paten. 



optionale Beschreibung der Rechenoperation (s.u.). 



Fig4a 



Operation ID 


Operation. BitCode 


Operation Type 


Jjj+MhspTonJc 




-1 


0 








unbekannte Operation 


0 


1 




111? 


TST 




1 


2 




112! 


NEG 


Mrtnn-f tr>rt 1 RotrA ft 4 ttil Hi Iflfl 
r«&yalltJI> | DcUdysuiiuuiiy 


^ 2 


4 




112! 


NOT 


lv.>...«~it£>-£fc 1 rvv/ortion inn 
DHWoldv invtsr Litsi unu 


3 


8 




102 


MOV I 


Tesxe «cani — >neyis»i*5n.vt*iwoii>j 


4 


16 




112+ 


ADDI 


Teste «cani BOGieren 


5 


32 




112- 


SUBI 


Tesxe <.ani buuiiaiuuicii 


6 


64 




113* 


MULI 


mn raster *^am muiiipiizieruii 


7 


1 28 




123/ 


DIVI 


ourcn Teste £.ani arviaieroii 


8 


256 




113% 


MODI 


L/Ivtsionsrest einer lesien tarn 


9 


51 2 




:I12* 


SHLI 


nesTaCant*rnai verooppein 


10 


1 .024 




:I12/ 


SHRI 


Coet7 qW Lmnl hfl IKiorAfl 
resttanrmai iitjiuioit»ii 


1 1 


2.048 




:I12| 


r\T} T 


DIIS einer loalell chilli iiiiuuiu^cii 


1 2 


4.096 




:I12& 


BKinT 
rtJNU -L 


Rife *»irM=»r fAQfAn 7nhl Ifischen 
Olio cllici 1 Oftici I * r»i II iwvi ioi i 


13 


8. 192 




:I12? 




Daw fV/onjU 1-\ZmYllAl^h m f ACtAm Bit 


1 A. 






:I12? 


CMP I 


Reg.[Verw.]-VergIeich m. fester Zahl 


1 K 


o^. / DO 


TI22 


MOV 


Quell -Rea rVl-> Ziel-Rea.[V.] 


1 R 
1 o 




1122+ 


ADD 


Reg . [ Verw. )- Addition 


17 


131.072 


. 1122- 


SOB 


Reg.lVerw.]-Subtraktion 


18 


262.144 


1123* 


MUL 


Reg. [Verw.]- Murtiplikation 


19 


524.288 


1133/ 


DIV 


Reg.[Verw.]-Division 


20 


1 .048.576 


1133% 


MOD 


Reg. [Verw. 1-Divisionsrest 


21 


2.097.152 


1122* 


SHL 


Reg.[Verw.]-mal verdoppeln 


22 


4.194.304 


1122/ 


SHR 


Reg.[Verw.]-mal halbieren 


23 


8.388.608 


II22I 


OR 


Reg. [Verw. ]-Bits hinzufugen 


24 


16.777.216 


II22& 


AND 


Reg. [Verw .]-Bits loschen 


25 


33.554.432 


1121? 


BTST 


Reg.IVerw.J-Veralelch m. Reg.-Bit 


26 


67.108.864 


1121? 


CMP 


Reg.[Verw.l-Vergleich m. Reg. [Verw. 


27 


134.217.728 


. :P00. 


JMP 


addiere teste Zahl -►PC/EIP*- 


28 


268.435.456 


CP1.< 


JLT 


Jump if CMP < 


29 


536.870.912 


CP1 1 > 


JLE 


Jump if CMP £ 


30 


1.073.741.824 


CP1.= 


JEQ 


Jump if CMP= 


31 


2.147.483.648 


CP1 !< 


JGE 


Jump if CMP > 


32 


4.294.967.296 


CPl!- 


JNE 


Jump if CMP * 


33 


92.0000.0000 


CP1.> 


JGT 


Jump if CMP> 


34 


$4.0000.0000 


CP1!< 


JPL 


Jump if ^ 0 


35 


$8.0000.0000 


CP1.< 


JMI 


Jump if < 0 


36 


$10.0000.0000 


CP1. ~ 


JCS 


Jump if Carry set 


37 


$20.0000.0000 


CP1 ! * 


JCC 


Jump if Carry clear 


38 


$40.0000.0000 


CP1.~ 


JVS 


Jump if Overflow set 


39 


$80.0000.0000 


CPU- 


JVC 


Jump if Overflow clear 


40 


$100.0000.0000 


C?2.< 


DJMP 


Decrement and Jump if Reg. < 0 


41 


$200.0000.0000 


PS1. . 


CALL 


P^/BP^-CUSP^/ESP*) ; + JUMP 


42 


$400.0000.0000 


SP11. 


RET 


(USP jU /ESP*) + -+PCJ£\P* 


43 


$800.0000.0000 


.1. . . 


I??? 


unbek. Integer-Operation 


44 


n ooo.oooo.oooo 


p 


F??? 


unbek. Floating-Point-Operation 
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45 


52000.0000.0000 


FF0 9 


FINIT 


mit FloatingPoint-Unit 


46 


54000.0000.0000 


FI12 


FIST 


store Fk>at.Point-Reg.-*lnteger-Reg. 


47 


58000.0000.0000 


IF12 


FILD 


load Integer-Reg. ->FloatinflPoint-Reg. 


48 


$1.0000*2 32 


IF22 + 


FIADD 


Floatingpoint add Integer 


49 


$2.0000*2 32 


IF22- 


FISUB 


Floatingpoint sub Integer 


50 


$4.0000 »2 32 


IF22* 


FIMDL 


Floatingpoint multipl. mit Integer 


51 


$8.0000*2 32 


IF22/ 


FIDIV 


Floatingpoint teile durch Integer 


52 


$10.0000*2 32 


IF21? 


FICMP 


Ftoat.Point-Compare Integer -►Ftegs 


53 


$20.0000*2 32 


: F02 


FLD# 


Konstante FloatingPoint-Register 


54 


$40.0000* 2 32 


.F12! 


FABS 


FloatingPoint-Betragsbildung 


55 ' 


$80.0000*2 32 


FF12 


FLD 


Floating Point-Kopieren 


56 


$1 00.0000* 2 32 


FF22 + 


FADD 


Floating Point- Addition 


57 


$200.0000* 2 32 


FF22- 


FSUB 


Floating Point-Subtraktion 


58 


$400.0000* 2 32 


FF22* 


FMUL 


Floating Point-Multiplikat ion 


59 


$800.0000* 2 s2 


FF22/ 


FDIV 


FloatingPotnt-Division 


60 


$1 000.0000* 2 32 


,F12@ 


FSQRT 


Floating Point- Wurzel 


61 


$2000.0000* 2 32 


.F128 


FSIN 


Floating Point-Sinus 


62 


$4000.0000* 2 32 


.F12@ 


FCOS 


Floating Point-Cosinus 


63 


$8000.0000* 2 32 


.F12@ 


FATAN 


Floating Point- ArcusTangens 


64 


$1*2 48 


FF22* 


FEXP2 


y:=y*2 x , o.a.Exponentialfunktion 


65 


$2*2 48 


FF22/ 


FLOG 2 


y:=x*lofl9V * o.a.Loflarithmusfkt. 


66 


$4*2 48 


FF21? 


FCMP 


Floating Point-Compare ->Flags 


67 


$8*2 48 


$111 


SMOV 


Move from a special Register 


68 


$10*2 48 


I$ll 


MOVS 


Move to a special Register 













Fig.4b 



1.Zeichen = Quelle, 2.Zeichen-Ziel t mit: 


? 


-unbekannt, Platzhalter fur alle moglichen folgenden 






= nichts 






= teste Zahl 




I 


= lnteger-Register-[Verweis]-lnhalt 




F 


= Floating-Point Register 




C 


- ConditwnCode-Register (unterstes Byte v.EFlags^/SFy 




P 


= InstructionPointer/Programmzahler (EIP„/PCy 




s 


= StackPointer-Verweis 






= Vergleichsoperation ->Flags 




$ 


= ein Spezial-Reg., wie Flags-, Control-, Debug-, ... 




! 


-Nicht fur Vergleichsabfrage im 4. Fold 


3-Zeichen = Anzaht der betr. Quetl-Reg. 




id. des Zielregisters, wenn auch als Source verwendet. 


4.Zeichen~Anzaht der betr.Ziet-Reg: 




mit Flags-Register ohne Instruction-Pointer. 


5,Zeichen = Rechen- W/rkung: 


? 


= unbekannt 






= keine 




t 


= Betragsbildung | Negation | bitweise Invertierung 




+ 


= Addition 






= Subtraktion 




* 


= Vervietfaltigung 




/ 


= Teilung 




% 


= Divisionsrest 




1 


= Bits setzen 




& 


= Bits I6schen 




@ 


= trigonometrische- oder Potentiatf unktion 




> 


= gr6Ber ? (Abfrage der Flags) 




< 


= kleiner ? (Abfrage der Flags) 






= gleich ? (Abfrage der Flags) 




At 


= Carry ? (Abfrage der Flags) 






= Overflow ? (Abfrage der Flags) 



Fig, 4c 
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-Tabelle: [ORT - von diesem OpCode + Anfangsbed. betroffene Register* Wirkung] 



OpCode -rfPKL: 


integer 


0..232-1 


Complete Instruction, truncated if > 4 Bytes 


IniConNr * (PK)* 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


Register ID dest . (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der Ausf Qhrung, s. RIT. 


Register ID source (PK) 


signed byte 


-1,0.. 127 


-1 oder ein mogliches Quell-Register, siehe RIT. 


value before change-:: ^: 


integer 


0..2 32 -1 


Wert von Geandertem vor Anderung. 


value after- change 


integer 


0..2 32 -l 


Wert von Geandertem nach Anderung. 


aradient if unsigned 'w* 


signed byte 


-128..127 


Erhohun^s-Gradient, wenn als unsigned definiert. 


gradient if signed 1 -' -M'- '•■ 


signed byte 


-128.. 127 


Erhahungs-Gradient, wenn als signed definiert. 


value_s^urc$i-; 


integer 


0..2 32 -1 


Wert von mdglichem Quell-Register-lVerweisl- 
Inhalt 


Operations_BitG6de 


number 


0..2 128 -1 


Bitmaske, die alle zutreff enden Rechenarten dieser 
Register ID dest / Register! Dsource -Komblnation 
kennzeichnet (z.B.: 2 + 2 = 2*2 bei gleichen Reg's). 
Werte siehe CIT. Berechnung siehe Fig. 1 9. 



Fig.S 



Fur jede Register- oder Register-Verweisin ha Its- Anderung derselben AusfOhrung gibt es hier einen 
Eintrag, der die Register-tVerweisl-Werte vor und nach der AusfOhrung, sowie dessen Anderungs- 
grad angibt, und einen Hinweis ein mogliches Ouellregister und auf die betreffende Operation, die 
stattgefunden haben kdnnte. (Packed, Teil-Word/Byte und BCD werden nicht berOcksichttgt.) 



OpCode-Lern-Tabefle: [PL T - ermrttefte Wirkung des OpCodes bei diesen AnfangsbedJ 



OpCode (PK) 


integer 


0.. 23 2 -1 


Complete Instruction, truncated if > 4 Bytes 


IniConNr (PK) 


signed byte 


-31.. 30 


A nf angsbedingung s- N r. 


active ChkSum corrupt : : 


boolean 


110 


Flag: aktives KB-Progr. Checksum changed 


inactive ChkSum corrupt 


boolean 


1|0 


Flag: inaktives KB-Progr. Checksum changed 


Exception Vect changed 


signed byte 


-128.. .0 


Register ID d. 1 . uberschriebenen Exception-Vectors 


multiple Exc Vect chg: 


boolean 


HO 


min.2 ExceptiorvVektoren wurden uberschrleben. 


Processor Mode Changed 


boolean 


110 


Rag: Prozessor-Modus wurde verandert (z.B. Trace) 


Number of Exception \ 


byte 


0..N+1 


Exception-NummeKggf-je+1) [0: = keine Exc] 


0pC6de_length_br jump 


sighed byte 


-128.. 127 


ElPjj/PC^jetzt N Bytes weiter bzw. zurflck; -1 28 = 
$FF=langer Sprung zuruck; 127 = $7F=langer vor. 


CCR before execution 


byte 


0..255^ 


Flags, die einen Sprung ausgeldst haben konnten. 


RegisterchangedBitCode 


number 


0..2 128 -1 


5"2*ORT.Register ID dest V ORT(OpCode,LfdNr) 


Register_source^BitCode 


number 


Q..2 12 *-1 


i s2*0RT.Register ID source V ORT(OpCode,LfdNr) 


max_Operatiora_BrtQpcie 


number(19) 


0..2 128 -! 


.S'ORT.Calcuiation BrtCode V0RT(0pCode,lniConNr) 


m in_Operations_BitCode 


number! 19) 


0-.2 128 -1 


CORT.Calculation BitCode V0RT(0pCode,lniConNr) 


time of execution 


integer 


0.. 23 2 -1 


DeciSeconds after (20.9.1994, 0:00:00,0 Uhr) 


cycles of execution 


byte 


1..255 


Taktzyklen der OpCode-AusfOhrung 


aim valuation 


signed byte 


-128.. 127 


Ziel-Erreichungs-Bewertung bei diesen Anf angsbed. 


gradient aim valuation 


signed byte 


-128.. 127 


Unterschied zu CLT( n-h IniConNr haim valuation 



Fig. 6 



Das letzte Adress-Reg. ist der StackPointer. Das letzte Daten-Register sei das "Energie" -Register. 
Als Adress-Register sei hier jedes Register bezeichnet, dessen Inhalt nicht nur ein Wert, sondern 
auch eine Adresse im Speicher sein kann, auf dessen Inhalt zugegriffen werden kann. 

Es konnen mehrere Register gleichzeitig verandert worden sein, deshalb zusatzliche 1 :n-Tabelle, bei 
der Register JD_dest die Identitat des geanderten Registers darstelrt. Als mogliches Quellregister fOr 
die Anderung konnen u.U. mehrere in Frage kommen - diese Menge erhoht sich weiter durch die 
Summe ailer moglichen Operationen. ~ 
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fOBT - ermittelte Wirkuna der OpCode-AusfOhrung aus v ersch. AnfangsbedJ 



r% ****** a a ' : CfPifi . - 


ii i icyci 


0..2 32 -1 


Complete Instruction, truncated if > 4 Bytes 


Execution counter V 


byte 


0..255 


Anzahl der OLT-Eintrage bis jetzt 


F a t a 1 Error_cdunter 


byte 


0-.255 


Anzaht der verursachten schweren Fehler: 
CheckSum_corrupt, Exception_Vect_changed, 
Trace_Bit_cheared, Processor_Mode_changed, 
Exceptions aufter Devide-Error, Overflow. 




byte 


0..255 


Anzahl der Oevide-Error oder Overflow -Exceptions 




signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl ist tanger Opcode | Sprung 


awn ftrtfnrln himn l**ii<ith* 


signed byte 


-128.. 127 


mrttlere OpCcxIe/Sprung-Lange von alien Ausfuhrunger 




boolean 


1 10 


min. eine Abweichung von der OpCode-Lange 




byte 


1 ..255 


mrttlere r Zeitverbrauch in Taktzykten 




boolean 


1..0 


min. eine Abweichung von der Anzahl der Taktzyklen 




QtnnRfl bvt© 


-128.. 127 


Wahrscheinlichkeit: Befehl schreibt in Register 


Register copy probability 


signed byte 


-128..127 


Wahrscheinlichkeit: Befehl kopiert Register 


Memory write j>rc^lwiity 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl schreibt in Speicher 


Memory copy probability 


signed byte 


-128.. 12V 


Wahrscheinlichkeit: Befehl kopiert Speicher 


Reg to Mem probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert Register d.Adr.Reg 


Mem to Reg probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert d.Adr.Reg. in Reg 


Muhti_Reg _write_prob 


signed byte 


-128. .127 


Wahrsch.: Befehl schreibt in mehrere Register. 


MultlMem write prob 


signed byte 


-128.. 1 27 


wanrscn.: Deiew scnrniDi tjurwfi ihciudio nui.noy. 


Multi Heg to Mem prop 


signea oyre 


-128. .127 


Wahrsch.: Befehl kopiert min. 2 Reg. d.min.2 Adr.Reg. 




cinnnri HvtR 


-128. .127 


Wahrsch.: Bef. kopiert d.min.2 Adr.Reg. in min.2 Reg. 


nil Rah riast RltCode 


number 


0..2 123 -1 


.sOLT. Register changed Bitcode V OLT(OpCode) 


— , ,«> Don. rJctot' Rft^rvlo 


I IUI 1 lUvl 


0..2 128 -1 


/"OLT Reaister chanoed Bitcode V OLT(OpCode) 


al^Regjsource^BrtCode^:; 


number 


U. .Z * * 1 


^ QLi.Kegister source tJiicoae v ul i wp^vhjci 


cut Reg source BitCode 


number 


- ~ii>A <. 
0..2'f*-1 


COLT. Register source Bitcode V OLu Opcode ) 


max_Operation_BitCode 


number 


0..2 128 -1 


.sOLT.max Operation BitCode V OLT(OpCode) 


min_Operation_BrtCc>de . 


number 


0..2 128 -1 


COLT.min Operation BitCode V OLT(OpCode) 


all Operation BitGode 


number 


0..2 128 -1 


SOLT.min Operation BitCode V OLT(OpCode) 


cut Operation BitCode 


number 


0..2 128 -1 


COLT. max Operation BitCode V OLT(OpCode) 


mav' u/nto v/aIhe* - * 
Ilia A WlflP VC|IU^3 


III Lw^jPI 


0..2 32 -1 


Maximun aller geschiebenen Werte 


miri write value 


integer 


0.. 2 32 -1 


Minimum aller geschiebenen Werte 






0..2 32 -T 


Mitt el we rt aller geschiebenen Werte 






0..2 32 -1 


maximale Differenz des geanderten Werts 


min write gradient 


tnfra^i AT 


n 332.1 


minimnln Differenz des aeSnderten Werts 






O 232.1 


durchschnittltche Differenz des geanderten Werts 


evBiuaieo source nepisier 


at^JIKfu L/yU? 


-1 ,0.-1 27 


Quell register ID (nach OBT-Auswertung) 


evaluated_source_NumRec, 


signed byte 


-128, -1, 
0..1 27 


-128 = LOB ist feste Quellzahl; 0..127 == weitere 
Quell register ID; -• = -1 (nach OBT-Auswertung) 


evaluated dest Register 


signed byte 


-1, 0..12' 


Zielregister nach OBT-Auswertung 


evaluated_dest_Register2 


signed byte 


-1, 0..12' 


mogl. 2.Zielregister nach OBT-Auswertung oder Flags 
(bei min. 2 echten ZfelReg. wird Flags nicht genannt). 


evaluated Operation ID 


signed byte 


-1.0..63 


wahrscheinlichste ausgefuhrte Operation (Ausw.) 


Confirmation counter 


byte 


0..255 


gleiche Auswirkung bei neuen Anfangsbedingungen 


max aim valuation 


signed byte 


, -128..12> 


' max. Wertvolligkeit des OpCodes fur Zielerreichung 


avg aim valuation ■ 


signed byte 


. -128..12> 


f mrttlere Wertvolligkeit d.OpC. fur Zielerreichung 


max_grad_aim - valuation 


signed byte 


t -128..12i 


' max. Erhohung der Zielerreichung gegenuber der kur- 
zeren OpCodeKombination ohne diesen OpCode (KB! 






i -128..12: 


f mittl. Erhohung der Zielerreichung durch letzten OpC. 



Fig. 7 



Datentypen: Boolean 1 Bit, BCD/Nibble 4 Bit Byte/char(1) 8 Bit, Word/short 16 Bit, DWord/lnteger 
32 Bit, QWord/number(19) 64 Bit, number/number ( 38. 0) 128 Bit (38 Digits £ 16 Bytes), varchar2(N) 
String variabler Lange aus max.N Character, long sehr langer String aus max(longDef) Character. 
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Die folgenden Kombinations Tabellen werden dynamisch angelegt, haben die gleichen N ° np K- 
Columns, wie die OBT bzw. OLT bzw. ORT. jedoch fur jede zusatzliche Code-Kombmations-Anzahl 
einen weiteren OpCode mehr im PK: : — 



Kombinatsons-kegister-TabeHe: ICRTUL / = Anz.QpCodes, fur die QpCode-Kombination, CRT(I)-ORT) 



&patve. 

OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination) 


{for an OpCodes} (PK) 


je integer 


0-2 32 -1 


{fOr alte Opcodes 2 bis ISM } 


OpCode N ARK):. 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


IniConNr (PK/ 


signed byte 


-31.. 30 


Anfangsbedingungs-Nr. 


Register ID dest (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der AusfGhrung, s. RIT. 


Register ID: source (PK) 


signed byte 


-1..127 


-1 Oder ein mdgliches Que II- Register, siehe RIT. 


{Gieicho Spaften, wie in. 
der OpCbde-Register- . 
TabetteJ ! " : " 


s.o. 


s.o. 


jede Kombinations-Register-Tabeffe bat unter dem 
PK die gleichen Spaften, die die OpCode-Register- 
Tabelfe auch hat 



Hg.8 



Kombinations-Lem-TabeUe: ICLTQ), i^Anz. OpCodes, fur die QpCode-Kombination, CLT(7) = OLT] 



OpCode i ! (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination ) 


{for aff OpCodes) (PK) 


je integer 


0-2 32 -1 


{fQr alle Opcodes 2 bis N-1} 


OpCode IM (PK) 


Integer 


0-2 32 -l 


Opcode N (letzter der Befehlskombination) 


InfConNr (PK) 




-31.. 30 


Anfangsbedingungs-Nr. 


(sonst gteiche Spaften, 
wie in der OpCode-Lem- 
TabelleJ 


s.o. 


s.o. 


jede Kombinations-Lem-Tabelle hat unter dem PK 
die gleichen Spaften, die die OpCode-Lem-Tabelfe 
auch hat. 



Fig.9 



Kombinations-Basis-Tabelle: [CBT(i), i=Anz. OpCodes, fur die QpCode-Kombination, CBT(1)=OBT) 



OpCode 1 ~ (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination) 


{for alt OpCodes} (PK) 


je integer 


0-2 32 -1 


{fur alte Opcodes 2 bis N-1 } 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


(sonst gfeiche Spaften 1 s.o. 
wie in der OpCode-Basis- 1 
1 Tabefle.) \ 


s.o. 


jede Kombinations-Basis-Tabelle hat unter dem PK 
die gfeichen Spaften, die die OpCode-Basis-Tabelle 
auch hat. 



Fig. 10 „ 

|CBT(max.) = CPT = Kombinations-Plan-Tabelle = Entste hung sort des Ergebnis-Programms. 




i 
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Proarammjerziel- und Bewertunqsfun ktions-Tabellen: 



Zietl&sungS' Tabeffe: 



Spaite: 



fAST - Losungen (aim-solution) aller gesteU t nn Proarammier-AufgabenJ 



Datentyp 



Aim ID 



(PK) 



Solution Nr 



aim Program 



Program length 



cycles of execution 



used Registers IBitCode 



used Operations Bitcode 



used aim Valuation Func 



Wertebereicb Bedeutung: 



short 



byte 



long 



short 



integer 



number 



number 



short 



0.. 65535 



0..255 



String 



1.. 65535 



.232-1 



1..2 128 -1 



0. .65535 



Identifier des Program mierziels 



laufende Nr des Losunasprogramms 



OoCode-Kombination des Losunps-Prg. als String 



Lanqe d. Losunos-Prgs in Doublewords . aufgerundel 



Ausfuhrungszeit des Los.-Pros in Taktzyklen 



Bitcode aller im L6s.-Prg. benutzt en Register 



Bltcode aller im Los.-Prg. benutzten Operationen 



Identifier der benutzten Zietnahe-Bewe rtungsfuntton 



Fig.11 



Z i^Bescbreiburu^-Tabelie: (APT - ^( prnaramm-Bescbreibung (aim-description) und identification] 
— — — : : Datentyp Wertebereicb Bedeutung: 



Spaite: 
Aim ID 



(PK)< short 



aim Description 



used Processor Mode 



all dest Register BitCode number 



al) source Register BitCode 



varchar2<32 



integer 



number 



0..65535 Identifier des Programmierziels 



£32 Bytes 



0-2 32 -1 



72T28T 



BescKreibung der Programmieraufgabe 



Hags uber CCR I Control-Register-Bits 



1..2 12 *-1 



Bitcode aller Eingabe-Repjster der Aufgabe 



Bitcode aller Ausgabe-Reoister der Aufgabe 



unused Reqiser BitGode i 



unused_Operatk>n_BrtCode 



aimjmplement_solutk>ns 



aim fulfil : valuation mode 



aimjfulfHIed Flag : Function 



aim Valuation FuncttpnlP; 



number 



1..2 128 1 



number 



0..2 12B -1 



Bitcode aller nicht zu benutzend en Register 



Bitcode aller mit Sicherheit nicht zu verwendenden 
Operationen (default « $000 0.0000:0000-0000) 



long 



String 



String aus AimJD's (words) fruherer, hier einzubin- 
dender Losungen. 



boolean 



on 



Ziel-Bewertungsfunktion; 0=SQL ; 1 = Maschinencode 



varchar2(99 



<99 Bytes 



booPsche Zjel-Erreicht Erkennungs-Funktion als String 



varchar2(99 



<99 Byte 



Zielnahe Bewertungs-Funktion als String 



Fig. 12 



Funktkm-fdentifikations Tabsno: (FIT - Tabeiie der Bewertun gsfunkti ons-Fragmente) 
a.) fur SQL-Funktionen: 

Spaite: Datentyp Wertebereicb Bedeutung: 



Function ID (PK) 



Function BitCode 



Function Type 



Function Flatten 



Function Template 



Function, Description 



signed byte 



n umber ( 1 9) 



char(5) 



byte 



signed byte 



varchar2(99 



varchar2(9 9 
Fig. 13a 



-1..127 



5 Bytes 



0..99 



-127..127 



<99 Bytes 



ldentrfikationsNurnmer der Teitfunktion 



BitCode dieser Teilfunktion 



Funktions-Name 



Q= value. 1 -unitar, 2 = binar, 3 = ternar, 



Funktions-Abflachungsgrad [pos = steiter, neg=flacher' 



SQL-Funktions-Template 



^99 Bytes 



optionale Teilfunktions-Beschreibung 
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F.ID 


Function BitCode 


F.Name 


FT. 


F.F. 


Function Template 


Function Description 


0 


1 


NUM 


0 


0 


< FolgeWert > 


es folgt eine Zahl 


1 


2 


ENGY 


0 


0 


ELT. energy after 


Energie nach Anderung 


2 


4 


GRAD 


0 


0 


ELT .energy after 
-ELT. energy before 


Energie-Erhohung 


3 


8 


VALUE 


0 


o 


CLT(n). <columnNr> 


Wert bus dem innair oer 
folgenden Column-Nr 


4 


16 


EREG 


0 


0 


< EnergieRegister ID> 


ID des Energie- Registers 


5 


32 


SGN 


1 


0 


SiGNl %s > 


Vorzetchen 


6 


. 64 


ROUND 


1 


0 


ROUND( %s, 0 ) 


gerundet 


7 


128 


INT 


1 


0 


FLO0R< %s ) 


abgerundet 


8 


256 


ABS 


1 


0 


ABS( %s ) 


Betrag 


9 


512 


NEG 


1 


0 


-( %s> 


Negation 


10 


1.024 


ADD 


2 


1 


( <%s)-M%s) ) 


Addition 


11 


2.048 


SUB 


2 


-1 


( (%s) - <%s) ) 


Subtraktion 


12 


4.096 


MUL 


2 


4 


( (%s) * (%s> ) 


Multiplication 


13 


8.192 


DIV 


2 


-4 


{ <%s) / (%s> ) 


Division 


14 


16.384 


MOD 


2 


-2 


MOD( %s, %s ) 


Divisionsrest • 


15 


32.767 


SQRT 


1 


-8 


SQRT( %s ) 


QuadratWurzel 


16 


$1.0000 


CBRT 


1 


-12 


POWER( %s, 1/3 ) 


KubikWurzei 


17 


$2.0000 


MIN 




-10 


LEA$T( %s, %s ) 


Minimum 


18 


$4.0000 


MAX - 


2 


-10 


GREATEST* %s, %s ) 


Maximum 


19 


$8.0000 


LN 


1 


-48 


LN( %s ) 


Logarithmus naturalis 


20 


$10.0000 


EXP 


1 


48 


EXP( %s ) 


nat. Exponent! a ifkt. 


21 


$20.0000 


LD 


1 


-32 


LOG( 2, %s ) 


Logarithmus dualis 


22 


$40.0000 


P0T2 




32 


POWER( 2, %s } 


2-te Potenz von 


23 


$80.0000 


SIN 




-64 


SIN{ %s ) 


Sinus 


24 


$100.0000 


COS 


1 


-64 


COS( %s ) 


Cosinus 


25 


$200.0000 


TAN 




127 


TAN( %s ) 


Tangens 


26 


$400.0000 


ASIN 




127 


ASIIM( %s ) 


ArcusSinus 


27 


$800.0000 


ACOS 


1 


127 


ACOS( %s ) 


ArcusCosinus 


28 


$1000.0000 


ATAN 


1 


t127 


ATAN{ %s ) 


ArcusTangens 


29 


$2000.0000 


SINH 


1 


40 


SINH< %s ) 


SinusHyperbolikus 


30 


$4000.0000 


COSH . 




50 


C0SH( %s ) 


CosinusHyberbol. 


31 


$8000.0000 


TANH 


-j— 


-127 


TANH( %s ) 


TangensHyperbol . 


32 


$1.0000.0000 


LOG 


2 


-64 


LOG( %s, %s ) 


Logarithmus 


33 


$2.0000.0000 


POT 


2 


64 


POWER( %s, %s ) 


Potenzierung 


34 


$4.0000.0000 


OR 


2 


1 


( (%s) | (%si ) 


bitweises ODER 


35 


$8.0000.0000 


AND 


2 


-1 


( (%s> & (%s) ) 


bitweisos AND 


36 


$10.0000.0000 


EQ 


2 


-127 


DECODE! %s, %s, 1,0) 


gleich 


37 


$20.0000.0000 


LE 


2 


-127 


DECCDE( GREATEST %s - %s. 
0 ), 0, 1,0) 


kleiner-gleich 


38 


$40.0000.0000 


GE 


2 


-127 


DECODEt LEAST( %$ -%s, 0 ), 0, 
1,0) 


grfl&er-gleich 


39 


$80.0000.0000 


FRAME 


1 


-10 


GREATEST! LEAST( %s, +127 
-128) 


in signed-byte Rahmen: 
max. = 127. mln.=-128 


40 


$100.0000.0000 


BITS 


1 


-64 


{1 & %s) +(2 & %s)/2 -M4& 


Anzahl Bits im vorigen 
Wert 


41 


$200.0000.0000 


S_REG 


0 


0 


AQT .all source Registers- 
BitCode 


Que 1 1 register- BitCode 


42 


$400.0000.0000 


D REG 


0 


0 


ADT.a// dest Registers BitCode 


Zielregister-BitCode 


43 


$800.0000.0000 


AIM_F 


0 


0 


VAU NSX .aim Jui fitted ^Flag- 
Function ) 


Ergebnis der Ziel- 
erreichungsfunktion 

















Fig. 1 3b 
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b ) Fur Maschtnensprache-Funktionen: 

Spa lte: Datentyp Wert&bereich Bedeutung: 



Function BrtCocje 



Operations BitCode 



Registers 



BitCode 



Function Name 



Function Type 



Function Ratten 



Function OpCodes 



signed bytej -1..127 



numberd 9)10.. 2^-1 



number 



number 



char(5) 



byte 



signed byte 



number 



varchar2(99! 



Q..2 12g -1 



0..2 



5 Bytes 



0..99 



-128..127 



1..2 128 -! 



<99 Bytes 



IdentifikationsNurnmer der Teilfunktion 



BitCode dieser Teilfunktion 

BitCode der verwendeten OpCodes in dieser Funktion 
BitCode der verwendeten Register in dieser F unktion 

Kufzbezeichnung der Teilfunktion 

0 = value, 1=unitar, 2 = b inar, 3 = ternar, 



Funktions-Abflachunqs^rad (1 = f(x) = x) 



Teilfunktion in Maschinensprache 



optionate Teilfonkuons-Beschreibung 



Func.lD 



Fkmc.BftC&& 



10 



11 



12 



13 



Qper.BftCode 



$A000.4008 



$0000.0002 



8 

16 



$0000.0200 



$0000.0400 



32 



$0000.0100: 
4A00.8018 



64 



$1000.0000: 
0000.0000 



128 



256 



512 



1024 



2048 



4096 



8192 



Fig. 



74a 



28800.0009 



$0000.8000 



$0000.8000 



$0001 .000O 



$0002.0000 



$0004.0000 



$0008.0000 



Fune.Name 



< energy > 



< energy; 



< energy > 



< energy > 



< energy > 



<D0)|(en> 



<FP0>|(en> 



s. 1 .4.2 



<en-1>|<en> 



<en-1>|<en> 



(en-1>|<en> 



<en-1)t<en) 



<en-1)l<en) 



<en-1)l<en) 



FRAME 



SGN 



NEG 



MUL2 



DIV2 



1L0G2 



ISQRT 



ICBRT 



MOV 



SWAP 
ADD 



SUB 



MUL 



D1V 



Func.QpCodes 



Function Oescript. 



s.u. Fund 



s.u. Func.2 



<NEG> 



<SHLI> 



:SHRI> 



s.u. Func.3 



s.u. Func.4 



s.o. 1.4.2 



<MOV> 



s.u. Func.5 



<ADD> 



<SUB> 



<MUL> 



<DIV> 



Qberlaufe verhindem 
Siqnum (Vorzeichen) 



Negation 



Division durch 2 



Multiplikation mtt 2 



Logarithmus dualis 



Square-Root 



Cube- Root 



Kopieren in Reg. vor 
Energy-Reg 



Vertauschen mit 
Reg, vor Engy-Reg. 



Addition mit 



Subtraktion 



Multiplikation 



Division 



Funktion: 
Fund 



Func.2 



Func.3 



Func.4 



Func.5 



^ ^^hinenoodeQbersstzuna u.a. Mnemon ic, hferam Beispfel Motorola) ' 
■m- II r r "V ™ ' rMPI -128.<B : JGE (+2) ; MOVI JM 28,<l 



mH iwm'i JL E<+2>; MOVI #127.<En CMP I -128.<E> ; JGE <*2) ; MOVI <M28,<E 
TStV; JgV<*3): MOV.#-UE); JMpW . JGT (+3) : MOV. #0.<E> ; JMP<*2); 

MOVI #+1,<E> 



MOVI # 31.D0; BTSTDO.^; JEQ<+3); DJMP DO.<-2) ; ADD! #1.00: MOVE DO X^ 
FILD <E> ; FSQRT ; FIST <E> 



MOVE <E-1) -tA7) ; MOVE <E).(E-1) ; M OVE (A7) + ,<E) 
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Tabelle der Bewertungsfunktionen] 



SDatte: Datentyp 


Wertebereich Bedeutung: 






± 32767 


Identifier der Bewertungsfunktionen (Energte neg.) 


Valuation_Functk>n_Type 


cnan i ; 


fc | M 


*E* — Energie-Bewertung, 'A* = WertvolKgkeit fur 
Programmierzielerrcichung, (ggf . spfiter wertere) 


Valuation Function Mode 


□OUICdll 




0 = SQL-Modus ; 1 = Maschinencode-Modus 


Valuation Function 


varchar2(99 


<99 Bytes 


Bewertungs-Funktion bzgl. Energie Oder Zielerreichung 


execution counter 


integer 


0-2 32 -1 


Anzahl der Funktions-Benutzungen 


used Functions BitCode 


number! 19) 


0..2 64 -! 


BitCodes der verwendeten Teilfunktionen 


Function ID Chain 


varchar2(99 


£99 Bytes 


Verkettung der Teilfunktionen (je Byte = Function ID) 


avg Func execution time 


integer 


0-2 32 -1 


mittlere Ausfuhrungszeit der Bew.Fkt. in Taktzyklen. 


boundary value counter 


integer 


0-2 32 -1 


Zahierf. Bewertungsergebnis = -128 I + 127 


low value counter 


integer 


0-2 32 -1 


Zahler f . Bewertungsergebnis in ±-16 


Valuation_Functjon_va lue 


signed byte 


-128.. 127 


Wertvolligkeit der Bewertungsfunktion = SAC. Set f- 
Vatuation Afm/Energyi Valuation Function, Values J 



ID 




M 


ValuatiW Fwfwtion ' ^1 - •"■ 


-1 


'E* 


0 


MAXJ MINI SGN( Energy Reg' -EnergyReg* ) • SQHT( EnergyReg'-EnergyReg* ) 

32- II CLT(i). Register changed BitCode &( I 2* Energy Register ID ) > . +127], -128] 


0 


'A' 


0 


MAXl MINI 16- II CLT(i). Register _changed_BitCode & ADT \all_dest_Register_BitCode } 
+ 16- /I CLT(i). Register source BitCode & ADT .all_$ource_RegisterJ!itCode > 
+ 32 ADT.a/m fulfilled _Flag_Function[ AimJD ) -CLT(i). Processor _Mode_changed 
-y*>CLT(i). cycles of execution -( CLT(i). active\ inactive jChkSum_corrupt ) 
-( CLT(i). Exception Jrectjshanged>0 ) -i CLT(i) .Number _of_Excaption>0 ) 
fc{ CLT(i). ObCode length or jump > 4 oder £ 0 ), +1 27}, -1 28] 


ex# 


used F. BitCode 


Function ID chain ; L 


ex.T 


bdy# 


tow# 


F.Val 


0 


$189.0040.983B 


2.5; 2,15; 12; 4,22,3,11,35,40,1,32,12; 1 1 ; 39 


0 


0 


0 


0 


0 


$EE9.0001.3AAA 


3, 1 1 ,42,35, 1 , 1 6, 1 2; 3, 1 2,41 ,35, 1 , 1 6, 1 2, 1 0; 

43, 1 ,32, 1 0, 3,7, 1 1 ; 3, 1 6, 1 ,5, 1 3, 1 1 ; 3,3. 1 1 ; 3,5, 1 1 

3.5.5.10; 3,8,5,10; 3,9,1,0,37,1 1;3,9,1, 5,38,1 1 ;39 


0 


0 


0 


0 



Fig. 15b 



Statuszeile Kunstiiches BewuBtsein: [SAC (artificial consciousness) - Statuswerte des KB-Programms] 



sJfJCTiLCf. 1 

Prog ra mm StartDate 


times tamp 


Zeit+Dat. 


Datum uns Uhrzeit des Programmstarts. 


actual Processor Mode 


integer 


0-2 32 -1 


Flags uber CCR 1 Control-Register-Bits 


actual CPT Index 


byte 


1..255 


CBT( max{\) = actual CPT Nr > = akt.CPT 


CxT counter 


short 


1.. 65535 


Anzahl des Aufbaus der dynamischen CxT-Tabellen 


Aims total 


short 


1.. 65535 


Anzahl der Programmierziele insgesamt 


Aims soluted 


short 


0.. 65535 


Anzahl geloster Programmieraufgaben 


actual Aim ID 


short 


0..65535 


ID des aktuellen Programmierziels 


Aim_Valuation_Mode 


boolean 


0|1 


Modus der Zielerreichungs-Bewertungsfunktion 
0 = SQL-Modus ; 1 = Maschinencode-Modus 


AimVal uatk>n_Function!D 


signed short 


0..32767 


Aktuelle VFT .Valuation Function JD bzgl. Ziel- 
annaherungs-Bewertung 


Aim_Self_Valuation_Func 


varchar2 
(400) 


max.400 
Zeichen 


Pt/SQL-Bewertungsfunktion bzgl. der Effizienz der 
Rahmen-Zielerreichungs-Bewertungsfunktionen 


Energy_Valuation_Mode 


boolean 


0|1 


Modus der Energiehandlungs-Bewertungsfunktion 
0 = SQL-Modus ; 1 = Maschinencode-Modus 


Energy Valuation Func ID 


signed short 


-1.. -32768 


Akt. VFT .Valuation Function ID bzgl. Energie-Bewert. 


Energy_Self_Valuation_Func 


varchar2 
(400) 


max.400 
Zeichen 


PL/SQL-Bewertungsf unktton bzgl. der Effizienz der 
Energie-Bewertungsfunktionen 


max Valuation Function 


signed short 


0..32767 


hdchste ID aller Bewertungsfunktionen in der VFT. 


min Valuation Function 


signed short 


-1.. -32768 


niedrigste ID aller Bewertungsfunktionen in der VFT. 



Fig. 16 
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Spaite: 

Energy _acti on 
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[EL T - bewertet energiespez/ffsche anfangsbedmq unasabhangige Handfungenl 
Datentyp Wertebereich Bedeutung. 



fPKJ 



IniConNr 

Energy before 



(PK) . 



number 



signed byte 



0..2 128 -1 



31 -.30 



max. 16 Byte OpCode-Kombination der Energie- 

Register verandernden Handlung. 

Anfangsbedingungs-Nr. 



integer 



0..2 32 -1 



Energie-Register vor dieser Handlung 



Energy after 



integer 



0..2 32 -1 



min Operations .BitCode 



number 



0..2 128 -1 



Energie-Register nach dieser Handlung 



max OperattonsBitCbde 



number 



0..2 128 -! 



Register changed BitCode 



number 



1..2 128 -! 



Register source^BitCode 



number 



l..2 128 -1 



BitCode der wahrscheinlich benu tzten Qperationen. 
BitCode aller moglicherweise benu tzten Qperationen, 
BitCode der hierbei veranderten Register. 



BitCode der hierbei ausgelesenen Register . 



used cycles of execution 



short 



1 ..65535 



Energy valuation;- 



signed byte 



-128.. 127 



Val uatkjnFunction^fD 



byte 



0..255 



Ausf Qhrungszeit der energiespezi fischen Handlung 

Erqebnis der akt. VET. Energy valuation Function 
benutzte Energie-Bewertungsfunktion 



Rg. 17 



EnBrgta-Basis Tabelle: fEBT - Auswertung der eneraiesoezirischen Handfungen] 



Spatte: i 
Energy_act$on jPK) 


Jatentyp i 
number 


werteDeren 


max. 16 Byte OpCode-Kombi nation der Energie- 


Execution counter , ! 


byte 


0..255 


Anzahl der ELT-Eintrage bis jetzt 


FatalEfTor^cbunt^r-v . 


byte 


0..255 


Anzahl der verursachten schweren Fahler: 
c^huuorA Fnhlnr antsorechen den Spalten 3-7 der 
Lern-Tabelle, auBer wenn Number_of_£xception = 
Oevtde-Error oder Overflow. 


low Error counter 


byte 


0..255 


Anzahl der Devide-Error Oder Overflow -Exceptions 


avg Energy afters 


integer 


0..2 32 -1 


mittterer Energie-Wert nach dieser Handlung 


all Reg dest BitCode 


number 


0..2 128 -1 


S ELT. Register changed Bitcode V ELT(OpCode) 


c ut_R eg_dest_BitCode 


number 


0..2 128 -1 


<TELT.Register changed Bitcode V ELT(OpCode) 


all Reg source BitCode 


number 


0.2 128 -1 


3 ELT. Register source Bitcode V ELT(OpCode) 


cut Reg source BitCode 


number 


0..2 128 -1 


CELT. Register source Bitcode V ELT(OpCode) 


rreix JDperation Jfo Code 


number 


0..2 128 -1 


is ELT. max Operation BitCode V ELT(OpCode) 


min_Operatk>n_BttG:ode^ \ 


number 


0..2 128 -1 


<TELT.min Operation BitCode V ELT(OpCode) 


all_Qperatiori_BitCode 


number 


0..2 128 -1 


S ELT. min Operation BitCode V ELT(OpCode) 


cut_Operation_BitCode 


number 


0..2^S-1 


CELT.max Operation BitCode V ELT<0pCode) 
Maximun aller geschiebenen Energie-Werte 


max write value 
min write value 


integer 
integer 


0..2 32 -! 
0..2 32 -1 


Minimum aller geschiebenen Energie-Werte 


avg write value ' 


integer 


0..2 32 -1 


Mittelwert aller geschiebenen Energie-Werte 


max write gradient 


integer 


0..2 32 -! 


maximale Differenz des geanderten Energie-Werts 


min write gradient. 


integer 


0..2 32 -1 


minimale Differenz des geanderten Energie-Werts 


avg write gradient/' 


integer 


0..2 32 -l 


durchschnittliche Differenz des geanderten Werts 


equal value probability . ; 


signed byte 


-1 28-. 127 


Wahrscheinlichkeit; Erqebnis immer gleich 


avg Energy gradient . 


signed int 


±2 3l 


mittlerer Energie-Gradient dieser Handlung 
Wahrscheinlichkeit: Gradient immer gleich 


equal Gradient probability 
avg cycles of execution 


signed byte 
short 


-128-127 
1.. 65535 


AusfOhrungszeit der energiespezifischen Handlung 


avg Energy valuation 
Valuation Function ID 


signed byte 
byte 


-128.. 12> 
0..255 


f Ergebnis der akt. VFT, Energy valuation Function 
benutzte Energie-Bewertungsfunktion 



Fig. 18 
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3.2 Flulidiagramm des KB-Programms: 



3.2. 1 CxTdhWertezuweisungen: 



ORTbzw. CRTQ): 



ORT. Register JD_dest : = log 2 < Bit<OLT.Register_changed_Mask>. dessen Veranderung hier 
betrachtet wird ) 



ORT.Register ID source := Register IP( C° ), if ORT.calculatton code > 0, sonst -1. 



ORT.value before change : = valuetRegister IP dest) , vor OpCode-Ausfuhrung. 
ORT. value after change := value( Register IP dest) . nach OpCode-Ausfuhrung. 



QRT.gradient if signed MAXI MIW ORT.value after chang e - ORT.value before change, +127 
ORT.qradient if unsigned : = MAX! MM ORT.value after change - ORT.value before change, + \27\ua\ 



V°) 



ORT.Operation_BitCode :- 1 .(R a9 sVRags 0 )&&V(V=V 0 )&&[ KF&&(V,*<0) 1 1 ZF&&<V,°=0) ] 
+ 2[(V,' = -V I '>)&&V-(V=V 0 )] +4[{V I , --V I 0 )&&V-(V-V°)] +8-[(V,' = 0lfl)&&V-(V=V°)l 
+ ! 6-f{Vr = V.o+OLBJ&aVlV^)] + 32-KV,' = V,»-0LB MAW-VB + 64-KV,' = V l o .0LB)&&V-(V.-V°)l 

♦ 1 28-KV,' = V. o /0LB)&&V"(V=V°)] + 256-MV,' = V l °%0LB>&&V-(V*V°)] + 51 2-[(V,' = V.2~QLB)&&V-(V. 
^O^V^V.^OLBJMVTV'-V^ 

+ 2 13 (R33sVR3gs o )&&V0r=V°>&&I(ZF=1)&&(2*0LBhV o )| |(ZF-0}&&l(2*OlB|V ) e ) ] 

+ 2^ (Rags'^Rag8°)&&V(V=VO)&&C NF&&(V,° <0lfi)| |ZF&&(V,° -0UM + 2 15 .[<V I ( =C I 0 )&&V"(V-V°)J 

+ 2 22.[<v^V l °/2C^MVl\r-V°)] + 2^^ 

+ 225.(R 39S ^R38S o )&&V0r-V°)&&((2F-1)&&(2X l o hV l < > )| |(ZF=0)&&l{2-C l o | V,°) ] 
+ 2 26 (RafisVRaB5 6 )&&V(V'=V°)&&[ NF&&(V,° <C,°)[ |ZF&&<V,° =C,°> 1 
+ 2 27 -[(IP* <, IP°)| |(IP , >IP°+A)]&&(R3SS'-Ragfi 0 )&&V(V-V°) 

♦ 2 28 .(0P' < IP°)| | (IP 1 >lP°+4)}&&(na9s'-H383 0 )&&V{V=V°)&&(HF&IVF|!NF&VF) -(-...VJccCCCR) 
+ 240.{[(IP' £ IP 6 ) 1 1 (IP* > IP° ♦4)]&&(V I * = V,"-! ) 1 1 (V,' = -1 naaCRags* -HaBS 0 )&&V{V-V°) 

+ 2 41 [( IP' = IP°±0LB )&&((SP) = IP o )&&(Rags , -Rags°>&&V"Or=V°) 

+ 2 42 [( IP' = -4(SP) )&&(Fb98 , -R8gs 0 )&&V(V , -V 0 )+2 43 .[(V 1 W, 0 )&a(l other Jrrteger_Operation_BrtCode)l 
^2 44 .[(V F VV F °)&&(lother_RoatinaPoint_Operation BitCod8)]+2 45 [(CCR-R3gs , =0)&&V|V F , = O)]- 

♦ 2 46 .[(v/ = c F °)&&v-pr=v°)] + 2 47 -[(v F ' = c,«>)&&v-tv-v<»)] + 2*a.[{v F l - v F ° + c, o >&&v-(v=n] 
+2 49 .[<v F * = v F o -d b )&&v-(v-v°)i + 2 50 .[<v F ' « v F *.q a >aANnr-v°B + 25 1 -[(V F ' = v F -/c°»&VTr«Hl 

+ 2 52 .(RaflS^Ftegs o )&&V0r-V e )&&[ NF&&(V F ° < C,°) | |ZF&&(V F ° =C,°)J 

♦ 253. [ ( v F - = l.0)| 1(V F ' =0.0)|| <V F ' = n) 1 1 (V F ' = e) =V°) 

+ 2 5 M(V F = -V F °)&&(V F ° < 0)&&V-(V=V°)1 + 2 55 .[(V F § =C F °)&&V{V^V ,> )] 
+ 2 56 . « v » = V F » + C F ° )&& V"(V = V°)] + 2 57 . [< V F = V F ° -C F ° )&&V-(V * V°)l 

♦ 258.1(V F ' = V F ° .<V)&&V(V' =m + 259[(V F ' = V F ° /V F ° )&&V"(V = V°|] + 2 60 [(VpW F ' = V F «>&&V-(V'=n] 
+ 2 6 MV F ' =sin(V F ')l&&V-(V-V 0 )+2 62 .[V F , =cos(V F °)3&&V-(V^V°)+ 2*3[<V F ' = atan(V F °»)&&V-(V-V < >)] 
*2 64 .t(v F ' = v F °.2-v F 1 0 >&&vpr.v°)] + 2 65 [(V F ' = v F .riog 3 (V F °)&&V-or-v 0 )] 

+ 2 66 (R3 S sVRa 9 s 0 )&&V(V , =V 0 )&&I NF&&(V F *> <C F «>| |ZF&&(V F ° »C F °M + 26 7 .[{V,' = C s * )&&V(V' - V)] 
+ 2 6a [{V s '=C, 0 )&&V"|V'-V 0 J] + ... f mit V =value_after_change (-»Flags), V* = value_before_change, 
C°=velue(RegisterJD_source). Es mufc hierbei uber alte Register_ID_source(Art) gechecked 
werden. Trotz gleichen Register-ID's im PK konnen mehrere Bits gesetzt werden [z.B. wg. 
4=2+2 = 2*2 = SHl(2) = ...3 . 



Fig. 19 



OLTbzw. CL TO'): 



OLT.Processor_Mbde_Changed := II EFIags^/SF^ & I ^2^CCR_Flags ) > 0 
ORT.value after change( Register ID eines Spezial-Registers ) 



OLT.aim_valuation := VFT.Aim_Valuation_Function( SAC.Aim_Valuatk>n_FunctionlO, ORT.xxxxx, 
Reojsters_changed_BitCode, Registers_source_BitCode, min_Operations_BitCode, 
max Operations_BitCode t used cycles of execution, .. . ) — 



CLT(n).gradie nt aim valuation := CLT(n).aim valuation - CLT(n-1).aim valuation 



alle anderen Tabellenfeld-Zuweisungen sind anhand der OLT-Beschreib ung in Fig.6 hinrelchend erkiart. 
Fig.20 
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OBT bzw. CBT(i): 



O BT . E xecution counter : = Execution counter +1 



OBTFatalError.counter:- FatalError_counter + < 0< OLT.NumberofJException * Devide.Error, 
Overflow ) 1 1 OLT.active_ChkSum_corrupt 1 1 OLT. inactive j:hkSum_corrupt | j 
OLT. Exception vect changed I 1 OLT. Processor Mod e changed ) 



OBT.JumpJongOp_probability : = MAXl MINJ Jump_probability + ( OLT. OpCodelengthor jump < 0 ) 
+ ( OLT .OpCode length or Jump_>4>, +1273,-1281 



OBT.avg_OpCodeJumpJength : = iexecution - counter*avg_OpCodeJump_length 
+ akt.OpCode jump length) / (execution counter + 1 ) 



OBT.OpCode_len_unconfirmed := OpCode_len_unconfirmed 
a kt. OpCode length ) 



OBT.avg_cycles_of_execution : = { execution_counter 
akt. cycles of execution ) / (execution counter -hi) 



OBT.exec_cycles_unconfirmed := exec_cycles_unconfirmed || (avg_cycles_of_executton * 
akt. cycles of execution ) 



OBT.Register_write_probability := MAXl MINI Register_write_probability + 2*1 ( min.Reg.ID <, 

ORT.Column_ID_0LT * max.Reg.ID J&& ORT.value_beforechange * ORT.value J3fter_change ] - 
1, +127], -128] 



( avg_OpCode_length * 



avg_cycles_of_execution 



OBT.Register_copy_probability := MAX| MIN[ MIN( Register_copy_probability + 2*[ ( min.Reg.ID £ 
ORT.ColumnJDJDLT <; max.Reg.ID )&& ORT.valueJ>efore_change * ORT.value_after_change 
&&{ min.Reg.ID < ORT.Column ID source £ max.Reg.ID )] -1, +127], -128] 



OBT. Memory_write_probability := MAX[ MINI Memor/_write_probabilrty +2*1 ( min.Adr.Reg.ID <; 
ORT.Column_ID_OLT < max.Adr.Reg.ID )&& ORT.value J>efore_change * 
ORT.value after change ) -1 , +127], -128] 



OBT.Memory_copy_probability := MAX[ MINI MemorY_copy_probabtlity +2*1 ( min.Adr.Reg.ID £ 
ORT.Column_ID_OLT^max.Adr.Reg.lD)&& ORT.value_before_change * 

ORT.value_after_change &&( min.Adr.Reg.ID <; ORT.ColumnJD_source S max.Adr.Reg.ID > ] -1. 
1271,-128] 



OBT.Reg_to_Mem probability : - MAX[ MIN[ Reg_to_Memj>robabtlity + 2*[ ( min.Adr.Reg.ID £ 
ORT.Column JD_OLT <; max.Adr.Reg.ID )&& ORT.value_before_change * ORT.value_after 
change &&( min.Reg.ID ORT.Column ID source < max.Reg.ID ) 1 -1, +1271,-128} 



OBT.Mem_to_Reg_probability : = MAXl MINI Mem_to_Reg_probabitity + 2*[ ( min.Reg.ID <; 

ORT.Column_ID_OLT <; max.Reg.ID )&& ORT.value_before_change * ORT.value_after_change 
&&< min.Adr.Reg.ID < ORT.Column ID_source < max.Adr.Reg.ID ) 1 -1, + 1271^-1281 



OBT.Mu!ti_Reg_write_prob := wie bei Register jwrite_probability, jedoch mit min.2 zutreffenden 
ORT.Column ID OLT -Eintragen. 



OBT.MultiJS/lem_write_prob := wie bei Memory_write_probability, jedoch mit min.2 zutreffenden 
ORT.Column tD OLT -Eintragen. 



OBT.Multi_Reg_to_Mem_prob := wie bei Reg_to_Mem_probability, jedoch mit min.2 zutreffenden 
ORT.Column IP OLT + Column ID source -Eintragen. 



OBT.Multi_Mem_to_Reg_prob := wie bei Mem_toJteg_probability, jedoch mit min.2 zutreffenden 
ORT.Column IP OLT + Column ID source -Eintragen. 



OBT.xxxReg source |dest_ BitCode: siehe Tabellenbeschreibung 



OBT. xxx calculation BitCode: siehe Tabellenbeschreibung 

. — . . — w# i adt i, 



OBT.max write value := MAX( max write value, ORT.va lue after change ) 



OBT.min write value := MIM( min write value, ORT.value after change ) 

. . t ^- ^ * — ...rifA %»ltin _1_ HRT Mi 



OBT.avg_write_value : = ( execution_counter * avg_write_value + ORT.value_after_change ) / 
(execution counter + 1) 



OBT.max_write_gradient := MAX( max_write_gradient, ORT.value_after_change - 
ORT.value before change ) 



OBT.min_write_gradient : = MIN( min_write_gradient, ORT.value_after_change - 
ORT.value before change ) 



un i .voiup ucimp tiiianaw / ■ — 

OBT.avg_write_gradient := ( execution_counter • avg_write_gradient + ORT.value_after_change 
ORT.value before change ) / (execution counter+1) 



un i .vamo uoimo uiiaiitfo t t !^,^*->*v»w — . , . ■ - — -7 

OBT.evaluated jsourceJNumJRegister : = Wahrscheinlichkeitsf unktion( xxx_Reg_source_BrtCode, 
confirmation counter ) '. : 
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OBT.evaluated des t Recisterttl := W ahrscheinlichkaitsfunktiont xxx Reg dast BitCode 
: rr ... i l .«i/»uni vrw Onorntinn Bit Code, confirm .ct 



OBT.evaluated dest Registerui := wanr SC n e m 1 .u,^.u ,,uM^M ,. tr . a ^ nf - fm gtf / 

riRT wa i„ a t«d O peration ID Wa hrscheinlichkeitsfunktionl xxx Of^^^^^ 0 ^ ^^ 
— c ~ *■ f\*Ar _i_ />v*cri 3nuivalenter OLT+ORTs-Eintrag mrt 



OBT.ev aluated Operation iu : = w anibww»i.Mi^. w .« » r „ . — Cintr3n 

OBT.Confirmation.counter := Conf lrmation.counter+ex/srt aquivalenter OLT+UKTs-E,ntrag mrt 

niedrigerer IniConNr ) 



OBT.max aim valuation := MAX( max aim valuation. OLT.aim valuation ) 



OBT.max m m valuation := wimvm ma* ■ ■ ■■■■ v...*.--™.. , , 

OBT.avg_aim_valuation := ( axecu tion_counter « avg_aim_valuation + OLT-a.m_valuat.on ) / 

(execution cou nter 4- 1 ) — — — : ■ — r~ 

CBT(n).max_gra d_aim_vatuat»on := MAX( CBT(n)max>m_valuation, CLT(n).a.m_valuat.on ) 

- CBT(n -1).max aim valuation. , — 

CBT(n) avg grad aim valuation : = ( execution_counter * CBT(n).avg_aim_vatuation 

+ CUT(n);aim"valuition ) / (execution counter -*- 1) - CBT(n-1).avg qrad aim valuation 

Fig.21 



3, 2.2 ELT und EBT - Wertezuweisungen: 



ELT.max Operations BitCode ;= OLT.max Operations OpCode 
BitCode : ~ OLT.min Oper ations OpCode 



ELT.Register changed BitCode := OLT.Registers changed BitCode 



ELT.Register source BitCode : « OLT.Register s source BitCode 



ELT Energy Valuation : = VFT.Energy_valuation_Function( SAC.EnergyJ/aluation 

Energy after, EnergyJ>efore, ReoJsters_changed_BitCode, Registers_source_BrtCode, 
min Operation s BitCode. max Operations Bit Code, used cycles of execution, ... ) 



FunctionID, 



ELT.ValuationJ=unctionJD := zur Berechnung von Energy J/atuation benutzte 
V FT. Valuation Function ID 



EBT.avg_Energy_after : - ( execution_counter * avg_Energy_after + ELT.Energy_after ) / 
(execution counter* 1) 



EBT.equal value probability := equal value probability 4- 2 ( a vg Energy after = ELT. Energy after ) -1 
EBT.avg_Energy_gradient := ( execution_counter * avg_Energy_gradient + ELT.Energy__after - 
ELT.Energy_before ) / (execution counter + 1) 



EBT.equal_gradient_probability := equal_gradient_probability + 2 ( avg_Energy_gradient - 
ELT.Energy after- ELT. Energy before ) -1 



EBT.xxx Operations | Registers_BitCode siehe Tabellenbeschreib ung _ — 

EBT.avg_cycles_of_execution := ( e xecution_counter * avg_cycles_of_execution + ELT.used_cycles- 

execution ) / (execution counter 4- 1) 



of execut ion ) / (execution counter* 1) . : - 

EBT.avg„Energy_Valuation : = ( exeoution_counter • avg_Energy_Valuation + ELT.Energy_valuation ) 
/ (execution counter-K 1 ) 



Frg.22 



3.2.3 Deflnitionen zum Lesen des Ftu&diagramms: 

| Anweisungen"! kennzeichnet eine Anweisung pder eine Anweisungsfolge. 
. ( B edingung erf Gilt ? > JA: verzweigt horizontal, NEIN: unten weiter. 

( CodeFortfuhrunp ) kennzeichnet eine Sprung-Marke zu taw. von einem anderen Teil des FlulSdia- 
gramms. 

\Anweteungs-Block \ kennzeichnet einen Block bereits vorher definierter Anweisungen. 



lm FluBdiagramm sind aufgrund der Aufwendigkeit nicht alle Details aknb.sch beschrieben, jedoch 
ist die Grundtage der Funktionsweise klar und verstSndlich dargelegt. Selbstverstandl.che D.nge, 
wie Cursor-Close, oder das mitfullen nicht explizit erwahnter, aber vorhandener und keinen 
besonderen Algorithmus bendtigender Tabeilenfelder, gilt als selbstverstandlich angenommen. da 
die Bedeutung der Tabeilenfelder bereits unter 3.1.2 erklart ist und deren Zuwe.sungen unter 

fr^FluSegramm bedeutet 'Eintrag in der ORT generieren und OBT aktuafisieren ' einen Verweis 
auf die Wertzuweisungsalgorithmen in Fig. 19-21. 



Fig.23 
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3. 2. 5 KB-Flu&diagramm: 



| alle Registerinhalte abspeichern. 



a.) Initiate Vorberertungen: 

1 



| alle Original-Exception-Vektoren sichern. 



1 



Prozessor in Ausgangszustand bringen: alle Breakoints loschen, die Flags In den Control- 
Register und iim oberen Word des Status/Flags-Registers initiieren. m 



I KB-Datenbank (s.o.) anlegen und initiale Tabsllenwerte laden (bz w. errechnenh 



| alle Exception-Vektoren auf eigene Abfangroutinen urnlanken. 



fur Exceptions, die zusatzliche Daten auf dem Stack abspeichern, eine besondere Exception- 
Routine, die die zusitziichen Paten mitberOcksichttaen. ; 



Eine Exc.-Vektorroutine zum . hochschalten in den Supervisormodus misbrauchen und diese 
Exception ausldsen (Prozessor schaltet dort in den Supervisor-Modus und arbeitet ab dieser 
Vektoradresse weiter, wo auch der weitere Programmverlauf steht). 



Auf dem Stack die EFIags* bzw. das Statusregistersy so poppen, daft bei dessen Ladung, 
beim Rucksprung aus dem Supervisor-Modus, das Trace^/Trap^-Flag gesetzt ist, urn danach im 



Single-Step-Modus zu sein. 



Auf dem Stack den E\P n /PC u so poppen, daft bei dessen Ladung, beim Rucksprung aus demj 
Supervisor-Modus, an einer vorgesehenen Teststelle fur OpCodes fortgefuhrt wind. | 



Initiale Testwerte, die dann zum OpCode-Test in die Register geladen werden, so vorbereiten, 
daft dann alle Registerinhalte unterschiedliche Werte aufweisen und auch an den Often der 
Adressregister-Verweise unterschiedlieche Zahlen stehen. ._ 



| DWord-QpCode Generator-Zahfer auf -1 = $FFFF.FFFF initiieren. 



| IniConNr-Zahler auf -32 initiieren. 



Fig.24a 
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b.) Basis-Lernen: 



I OpCode-Generator-Zahler urn 1 erhohen und IniConNr = -32 initiiern. 1 
T ^ 

t ^at OpCode zum 2.mal $0000.0000 erreichtjj y-^andlu^ (Fi_Sb24c) ) 

I | IniConNr urn 1 erhdhen. 1 
| 1 

'< ( In iConNr > 30 ?_J 

T 



1 DB-Commit | 



Alle Register-Werte und Adressregister-Verweisinhalte auf ICT.Register_value( IniConNr ) set- 
zen; ab Teststelle 8 x NOP schreiben (dahinter steht die Fehlerroutine fur Traced/Trap^ Flag 
geloscht) und generierten QpCode-Wert daruber an die Tests telle schreiben. 
4- 



Riicksprung aus dem Supervisor-Modus ausfOhren: Test-EFIags*/SR„ werden geladen und 
dabei das Single-Steppen eingeschaltet. Der EIP„/PC^wird mit der Test-OpCode-Stelle 
geladen und der dortige Test-OpCode ausgefOht. 



Analyse; 



Nach der OpCode-AusfOhrung wird die Wirkung seiner Ausfuhrung 
analysiert und das Ergebnis in einem Anatyse-Code gespeichert: 



tin der Lern-Tabelle Eintrag mrt Key = {OpCode, IniConNr}, confirm, counter =1 g enerieren. I 



OLT.Numberj>f_Exception, Flags _be- 
fore execution, etc. eintragen; OBT* 



< Wurde eine Non-Trace -Exception ausge!6st ? >-> 

— — | — 

I 

< Wurde Qberhaupt keine Exception ousgei&stJ_ )-+ 1 OLT.Processor Mode changed, OBT* | — > 

es wurde Trace/Trap ausgelo st - Analyse der OpCode-Auswirkung : 
I KB-Prg.-CheckSum und die Checksum der inaktiven Kopie des KB-Prgramms erm itteln. ~| 

■A* 

< Checksum des aktiven KB-Prg. *s verandert ? )-» 



OL T. active ChkSum corrupt setzen, an 
aquivatente Stelle des inaktiven Codes 
springen und ehemate aktiven Code repa- 
rieren; OBT* • 



( Checksum des inaktive n KB-Pr g' s veran dert ? }-> 

— , 

< Wurde ein Exceptjon-Vektor Oberschieben ? >-» 



inactive jChkSumjzorrupt'RaQ setzen, 
und inaktiven Code reparieren; OBT* 



alle Exception-Vektoren wieder neu setzen, 
in OLT. Exception _Vector_changed dessen N 
eintragen, Eintrag in der ORT generieren; OBT 



Vergleich des E\P % IPQ U auf Stack (durch Trace gepushed) mit der Test-OpCode-Adresse j 
und setzten vo n OpCode length or jump entsprechend der Befehls- oder Sprung-Lange. | 



I , 

( Wurde der IP nicht urn 7.. 4 Bytes erhOht_Z> -> \OLT.OpCode length o r jump, u.s.w., OBT*\ 
" 1 " ~~~ 



Wenn OpCode kurzer als DWord war, erhohe Generator auf $ < Byte > FF.FFFF bei Byte- 
OpC, bei Word-OpC. auf $<Word>.FFFF und bei 3-Byte-OpC auf $< Word-Byte >FF. 



I Vergleich des d. Trace gepushed EFIags-r/SR/, auf dem Stack mit dem vorheriqen Test- Wert 



{ Wurde_ ein Registervvert id. Rags verandertTy * 
Loop Tuber alle Kegister: I 



Eintrage in der ORT, OLT generieren und OB" 
aktualisieren. Wenn "Energie" -Register veran 
dert: ELT-Eintrag und EBT aktualisieren. _ 



{ Wurde das Ziel eines Adres^BeQ^ver&ndertry ^ 
Loop uber alle Adr.Keg.: | ~ 

I 



ORT- und OLT-Eintrage generieren und OBT 
aktualisieren. 



Ffg.24b 
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cj Doppel-OpCode-Handeln: 



i Beofnn DoppelOpCodeHandem [nach Ende Basis-Le rnen - Fig.24bJ) 



i - 

OBT-Auswertung: mittels Wahrscheinlichkeitsfunktionen werden evaluated _sourceJNunUHegmer] 
aus den OBT xxx Reg source BitCode, evaluated _dest_Registerf 2] aus den xxx_Reg_dest BitCode 
und evaluated o'oerediion ID aus den xxx Operation BitCode ermitte lt (ie mit confirmation counter) 



Letztes Datenreqister ats ■Energie 1 ' -Register definieren und au f einen mittksren Wert setzen. \ 
"""" ^ 



Cursorl uber die OBT offnen. 



| Fetch aus Cursor! die nachste Zeite aus der OBT. ^ I 

( Tri r i»-n P nnda-manen (Fig. 24c) W Fetchl empty - vorderer OoCode abge arbeitet ? > 

/ Jump longOp probability > O oder Y[ADT.unused_Register_BitCode(AsmJD) \ 



AfOBT. cut source Reg BitCode \OBT.cut dest Reg BitCode) J > O ? / 



< Execution counter / OBT. OpCo de Fata/Err or counter ( OpCodel ) __<_5? $ 



2. Cursor uber die OBT flffenen. 



Fetch aus Cur sor2 aus der OBT. 
1 



< Fetch2 empty - hinterer O^Code abgearbeitet ? > 



/ JumpJongOp probability > 0 Oder T[ADT.unused_Register_BitCode(Aim_ID) \ 

\ &(QBT.cut source Reg BitCode \Q8T.cut dest Reg BitCodelHOgCJ) > 0 / -y. 

< ( Execution c ounter / OBT. OpCode FatalError counter (OpCode2) < 5 ?) 

•-. i . 



lniConNr= -32 initileren. 
1 



IniConNn 



- ilniConNr > +30 ?) 
4- 



i Initiierung und Ausf uhrung mit den Anfangsbedingungen der IniConNr wie 
I beim Basis-Lerrien, nur jetzt <ur den Doppel-OpCode. 

liGleiche Verfahrensweise, wie im Analyse-Block des Basis-Lernens <Fig.24b) 
Inur Eintrage ietzt in CRT(2), CLT(2) und CBT(2). 



□ 



"Energie "-Register um 1 erniedrigen. 



1 



r i 

{1st " Energie" -Register im mfttleren oder hohen BereicbTJ »— 1 

IEBT.Energy_specific_action mit hoher energy action _vaiuation und hohem I 
confirmation counter auswahlen und ausfuhren. ■ 



Analyseblock wie oben. 



Fig ,24c 
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d.) Triple-OpCode-Planen: 



Zeichnungen Seite 19/ 19 



( Beginn Triple -OpCode-Planen [nach Ende Doppel-OpCode-Handeln - s.o.J) 

4- 



OBT-Auswertung: mittels Wahrscheinlichkeitsfunktionen werden evaluated 'source JNum]Reg[ister] 
aus den OBT.xxx_Reg_source_ BitCode, evaluated _dest_Registerf 2] aus den xxx Reg dest_BitCode 
und evaluated Operadtion ID aus den xxx Operation BitCode ermittelt (je mit confirmation counter) 

4 



Cursor! uber die CBT(2) offnen. 



Fetch aus Curso r! die nachste Zeile aus der CBT(2). 



4r 

( Quad-O pCode-Planen )<-( Fetch 7 empty - vorderer OpCode abgearbeitet?_ 



) 



^ 

/ JumpJongOp jjrobability > 0 ocfer Y [ADT. unused Register BitCode! Aim JD) \ 
\ ^(QCJT^cu^sgurge^Re^ 8itCode\OBT(2):cu±_dest RegJBitCgde} I > 0 ? /' 

( E xecution counte r / C BT(2). OpCo de FatalError counter (OpCode I) < 5 ?} - 

4^ ' 



1 


Cursor2 uber die OBT dffenen. 


1 




1 


Fetch aus Cursor 2 aus der OBT. 


i 



(£eteh2 empty - letzterr OpCode abgearbeitet? > 



r 

t 



/JumpJongOp probability > 0 oder TfADT. unused } Register _BitCqde( Aim ID) \ 
\ &(OBT.cut_sourwJ1eQ BitCode [OBT. cut dest Reg_BitCoden„ >JO___? / 

< Execution counter / OBT, OpCode FatalError counter < 6 ?) 

4- 

i 



lniConNr=-32 initiieren. 

1 



tniConNr* + 



- 4 IniConNr > +3Q ? > 
4 



Initiierung und Ausfuhrung mit den Anfangsbedingungen der IniConNr wie 
beim Doppel-OpCode-Handeln, nur jetzt fOr den Triple-OpCode. 

4^ 



[Gleiche Verfahrensweise, wie im Analyse-Block des Doppel-OpCode-Handelns 
(Fig.24c), nur Eintrage jetzt in CRT(3), CLT(3) und CBT(3). 



Energieregister decrementieren und ggf. gleiche Auffullversuche wie beim 
Doppel-OpCode-Handeln mit aquivalenter Handlunpsbewertungsanalyse 



Fig.24d 



Verfahrensweise fOr hdhere Kombinationen analog, mit CxT(n). 
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